1

我有幾個查詢表,我正在通過我的應用程序管道過程中。這些是推動網站下拉的表格。他們沒有業務邏輯,但他們需要從應用程序的體系結構繼續訪問數據庫。查找表 - 在哪裏放置n層架構

當前的體系結構具有數據層,業務層和表示層。所有數據庫調用都在數據層中(使用模型對象和存儲庫)。業務層調用數據層,BL對象轉換數據層對象。表示層然後調用業務層並使用業務對象。 (基本上用戶界面 - >服務 - >知識庫)

我只是把它看作是一種浪費,因爲當沒有業務邏輯時,必須通過業務層來解決這個問題。我不介意在這個體系結構中添加一個Lookup層或Common層,但我不知道它適合在哪裏,或者我會如何將它融入到當前流程中。關於如何去做這件事的任何想法都會有幫助。

編輯:我想我真的很想知道如何在這裏合併一個公共庫,所以我可以添加查找。公用圖書館應該位於業務層和用戶界面之間,還是應該成爲業務層的「替代品」?或者我甚至需要一個通用庫?

回答

4

不知道你achitecture什麼...

我建議使用現有的BusinessLogicLayer和BusinessLogic。

這看起來可能是多餘的,因爲這些查詢查詢沒有業務邏輯。

但是,至少代碼將遵循現有的約定/方法。

而且,如果將來引入了businesslogic或查找條件,則不必更改PresentationLayer。

+1

同意 - 這是我的經驗,「簡單查找」通常不會很簡單。在一兩個(或七個)版本中,他們將獲得特殊情況和規則。現在避免業務層管道將在稍後給您帶來痛苦。 – Bevan 2010-08-16 22:18:03

+0

+1是的,將代碼分層並不總是一種無限的收益,但是你會感激你做到的。如果你始終如一地實施架構,你最終應該開發出有效的方法來完成這些常規管道任務 - 最終它應該不會更慢(如果不是更快),採取「漫長的道路」。 – 2010-08-16 22:36:38

0

爲了保持一致性,您應該通過業務層進行探究。該層中的代碼在第一次迭代中可能非常薄,以供查找。