在Visual Studio中設置「企業」項目的最佳實踐？

Question

我正準備爲6名員工（包括我自己）的小型企業開發企業級應用程序 - 在您問及爲什麼6人公司需要企業應用程序之前，我們有很多正在進行的很多過程和工具需要簡化它）。一如既往，我試圖按照建立項目的最佳做法;我打算使用.NET 3.5，數據庫在Windows Server 2003/SQL Server 2005上。

在開發和測試解決方案時，我應該在我的主項目中擁有一切嗎？我的意思是... Visual Studio 2008 Professional允許您擁有「數據庫項目」以及所有其他類型的項目。對於這個應用程序，我將需要：包含創建和測試腳本爲新的數據模式

包含實際的代碼/應用C＃項目

• 數據庫項目：
  1. 面向客戶的網站使用ASP.NET MVC網站（）
  2. 後端的訂單處理系統，可能是基於網絡的，但可能是「智能客戶端」
• SSIS項目containin g軟件包到ETL由我們的供應商提供的「實時」應用程序數據，並從現有客戶和訂單數據遷移到舊數據庫。對於SQL Server報表服務

基本上

報告的項目，我想知道如果這是一個好主意，有所有這些作爲一個龐大的Visual Studio解決方案的一部分（姑且稱之爲「EnterpriseSolution」），或者如果我應該把它們分開並分開處理。我看過的大多數書籍和網站都將它們包括在一起，但他們也假設了一個由開發人員，DBA，架構師等組成的團隊 - 在這種情況下，我將他們全部合併爲一個。由於我們需要在實時環境中加載新供應商的產品（開始銷售它們），所以在編寫其餘應用程序之前，數據庫項目和至少一些ETL過程需要完成並加載到生產環境中。

我對我該如何開始構建這個有點不知所措，但是我想在開始編寫代碼並開始編碼之前想出一個總體計劃。

關於如何解決這樣的項目的任何建議？

Answer 1

使用一個解決方案與其中的幾個項目絕對是一個好主意。如果你想使用ASP.NET MVC爲每一層定義一個C＃項目：MVC Web，服務層，數據訪問層和單獨的測試項目。 您可以從Rob Conery的Storefront示例應用程序或Oxite中瞭解到。

您可以嘗試使用也指導包從模式&實踐團隊：

http://msdn.microsoft.com/en-us/practices/default.aspx

Answer 2

我所做的是爲每個獨立的項目創建單獨的解決方案，然後開始將它們集成到更復雜的解決方案中。這樣你可以只加載部分應用程序進行單元測試或調試。

例如，在一個多層應用程序中，我將爲數據層和單元測試項目創建一個獨立的解決方案。另一種解決方案將包括數據層和業務對象層與單元測試一起工作。完整的解決方案將包括上述項目加上UI項目

這樣我可以加載和測試我的應用程序的每個部分。

Answer 3

我喜歡從一個解決方案開始，直到它變得如此之大，以至於構建時間明顯變慢。

你如何做到這一點取決於系統的不同部分如何相互連接。最簡單的方法是採用面向服務的體系結構。然後每個服務都可以有不同的解決方案，而前端則是自己的解決方案。

但是，我真的會推薦你用一種解決方案開展工作，只有在需要時纔會使事情變得更加複雜。它很高興能夠通過點擊來構建一切。

Answer 4

如果您需要分解稍後可以做的元素，只要保持對象鬆散耦合，就沒有理由讓應用程序不能全部集成在一箇中。

有單獨的項目的一個好方面是，您可以成功編譯一個部分，而其他部分不完整，只需卸載它們。

Answer 5

我會建議創建一個「空白解決方案」來啓動將是名爲EneterpriseSolution的文件夾中的* .sln文件（稱爲EnterpriseSolution.sln）。可以從「其他類型」創建空白解決方案。然後，我會添加您所描述的其他部分作爲單獨的項目，每個部分位於「EnterpriseSolution」文件夾下的自己的文件夾中。

例如，每個面向客戶的網站都會有自己的項目文件夾。它看起來像你將有多個網站，所以如果你使用一個解決方案包裝，你將需要確保你爲每個網站設置不同的「端口」。但是，您也可以創建不同的解決方案「包裝器」（作爲一個空白的解決方案，然後項目引用您想要的項目），以便將每個網站分別包含在您的文件夾結構中，以便您可以專注於企業解決方案的一部分。但是身體上你會知道一切都在哪裏以及它是如何組織的。

這樣，當您通過Windows資源管理器查看企業解決方案文件夾時，您將看到唯一的解決方案文件和項目文件夾。

謝謝，祝你的項目順利。

Answer 6

首先，數據庫項目是偉大的東西，我強烈建議將它用於您的數據層。

我會按項目分開，因爲它很有意義，但將它們全部保存在同一個解決方案中。

Answer 7

我發現它最方便的維護單獨的解決方案，客戶端和服務器端的代碼。這假設服務器提供了一個穩定的接口，如Web服務或WCF接口。隨着時間的推移，隨着時間的推移，你可能會使用多種客戶端技術（Windows，web ...），並將這些技術集羣分開存放在自己的解決方案中，這樣可以讓事情更簡單。

如果您正在尋找一個好的架構示例，請參閱CodePlex上的Northwind Starter Kit。 Dino Esposito和Andrea Saltarello在閱讀「Microsoft .Net: Architecting Applications for the Enterprise」時發現了這一點。

羅斯文入門套件是由管理 設計（http://www.manageddesigns.it） 和意欲生產的樣品 應用設計和實現.NET 分層應用體系結構時要使用作爲藍圖 。該 應用程序使用標準 Northwind數據庫，如包含在 微軟SQL Server和Microsoft 訪問：爲了 安裝和運行入門工具包都需要在 數據庫架構進行任何修改。

我同意@Chris Ballance的觀點，即包含數據庫項目可能會非常有幫助。但請注意，DB項目看起來有點複雜，因爲它會同步項目和參考數據庫結構。

+ tom