架構更大的應用程序

我爲在美國大多數州提供某些類型的金融諮詢服務公司工作的衛星部件。我們目前有一個非常簡單的CRUD應用程序，用於管理客戶以及我們爲每個客戶執行的資產和服務信息。它只關注所有位置共有的基本數據點和流程 - 最不常見的分母。架構更大的應用程序

現在我們要實現用於跟蹤，同時保留核心國家爲導向的制度有所不同的州，不同的數據點和進程的支持。像這樣： NationalWithStates

我正在使用的堆棧是ASP.Net和SQL Server 2008.國家應用程序是一個相當簡單的Web窗體的事情。它的數據訪問層是一個圍繞LINQ to SQL實體和datacontext的倉庫包裝。目前除了CRUD操作之外，幾乎沒有商業邏輯，但隨着每個州的複雜性被引入，會有更多的業務邏輯。

那麼，如何在教學貫徹衛星碎片...

剛開始glomming的功能和追求泥
的大球建立了一系列的衛星應用程序，再利用數據 - 訪問層，但在其他情況下是獨立的
在規則引擎（la Windows工作流）中投入（金錢和/或時間）並將每個狀態的唯一位作爲單獨的規則集進行隔離
投資（時間）in一個MEF的插件框架，並將每個狀態的功能實現爲ap lugin
別的東西

理想的用戶體驗會顯示爲一個單一的應用程序，可以無縫地適應它的介紹和流程，任何位置的用戶與合作。這特別有用，因爲有些用戶使用多種狀態的資產。所以有一場針對二號的罷工。

我與MEF或WF沒有經驗，所以我的大部分問題是我是否是甚要麼旨在解決的問題類型。他們都聽起來像是基於炒作，但可能會變成一個圓洞的方形釘。

在所有情況下，每個狀態都會引入新的數據點，而不僅僅是新進程，所以我會想象數據訪問層會增長以適應添加新表和列的需求，但我全都替代它。

編輯：我試圖想一些例子，我可以分享。可能有一種情況是，我們在一個州提交涉及客戶資產的某些法律文件。申請的屬性和工作流程與其他可能需要類似申請的州不同，所涉及的資產可能具有完全不同的屬性。其他國家可能根本沒有可比較的申請，還有一些國家可能有一系列不斷增加的申請，要求知道該州特有的其他相關實體。

來源

2009-06-01 Rex Miller

從Strategy設計模式開始，它基本上允許您勾畫出一個「佔位符」，在運行時由具體的類替換。

您必須勾畫核心應用程序和「插件」之間的清晰界面，並且您有每個策略都實現該功能。然後，在運行時，當你知道用戶正在處理哪個狀態時，可以實例化適當的狀態策略類（可能使用factory method），然後調用其中的通用方法，例如，像

IStateStrategy stateStrategy = StateSelector.GetStateStrategy("TX"); //State id from db, of course... 
stateStrategy.Process(nationalData);

當然，這些策略都應該利用現有的數據層等

的（明顯），用此溶液下行，僅僅是你會被硬編碼爲每個規則狀態，並且無法在不更改代碼的情況下透明地添加新規則（或新狀態）。不要被愚弄，that's not a bad thing - 你的商業邏輯應該在代碼中實現，即使它依賴於運行時數據。

來源

2009-06-02 05:38:09 AviD

順便說一句，只是一個注意你所有懷疑thomases - 這裏（最後）是設計模式的價值的完美例子:-) – AviD 2009-06-02 05:45:34

只是一個想法：無論你做什麼，完全碼3個國第一（與2你還忍不住要重複相同的代碼，更是太費時，如果你決定改變設計）。

我必須承認，我完全不知道有關規則或WF。但是不可能只有一個大笨蛋的ASP。Net包含文件，其中包含與主邏輯分離的狀態說明，不包含任何其他語言/程序？或者僅僅是事實：每個州都引用了很多完全不同的功能，而不僅僅是一些位？

來源

2009-06-01 23:01:55

架構更大的應用程序

回答

相關問題