.net中集中式數據庫應用程序的設計/架構建議

Question

我是初級.NET程序員。 我必須開發一種應用程序，該應用程序可以在本地環境中為少數用戶（大約8個）處理銷售，客戶和提供者（還有很多其他事情）。 應該創建一個完整的東西，以便使用集中式數據庫在本地使用。 我的架構從上到下都是這樣的：

1.Windows窗體上的UI。

2.用於處理用戶請求的控制器

3.Bussines對象是Entity Framework生成的對象

4.SQL數據庫

顯然，我已經知道這不是架構的最佳方法，但我想使其盡可能簡單。 我已經做了很多研究，但是問題的數量似乎正在擴大，因此我一直在尋找有關此特定問題的指導，以便在擁有自己喜歡的推薦體系結構后可以專注於研究。 抱歉，我對這個問題不知所措。

Tnx幫助新手。

Answer 1

您所描述的內容似乎是初級開發人員級別的一種好方法。

有許多因素會影響哪種架構適合項目。 與一勞永逸的應用程序相比，時間，進度，金錢，簡單性或復雜性，可維護性和將來的開發擴展。 由於數據模型或與某些未知系統的集成，將來的將來版本是否可能需要大量重寫？

第一次迭代后，沒有應用程序是完美的。 任何優秀的開發人員都會隨着技術技能和知識的增長而找到無數種改善項目的方法。

話雖這么說，數據庫和實體框架方面的工作還是很不錯的。 EF將使您快速專注於功能而不是基礎架構。 您可能已經將EF與其他對象模型套件或基於傳統存儲過程的方法進行了權衡。

UI可能由客戶或業務需求決定。 唯一的重大決定可能是Intranet Web應用程序，因此您不必擔心在用戶計算機上安裝軟件。

控制器/類庫/業務層很有意義，因此您不必直接在Winforms代碼中針對EF編寫查詢。 這使您可以更輕松地提取UI並用其他方式替換。

您所概述的所有內容都會在不知道確切情況的情況下引發任何危險信號。 繼續采用這種方法，看看它如何發展。 完成后，請考慮該架構的哪些方面面臨挑戰，冗余或其他麻煩。

Answer 2

如前所述，由於已生成實體框架對象，因此您可能希望在Controller和Entity對象之間具有一個或多個Model級別。 通常，一個特定的視圖具有來自多個實體的數據。 如果您沒有控制器可以訪問的另一級模型，通常會發生的是將業務邏輯遷移到控制器。

換句話說，控制器將創建模型，並且模型將知道如何與實體進行交互。

請注意，由於您在＃2中引用了Controllers，因此我假設您正在使用MVC模式。