理想的.NET架構？

我從ASP.NET應用程序的角度來寫這個問題。但是我意識到它也可能適用於其他環境。理想的.NET架構？

有這麼多的方法來開發一個ASP.NET網站的共同元素。下面是一些我所遇到：

LLBLGEN
亞音速
的LINQ to SQL
實體框架
的CodeSmith + .netTiers
NHibernate的
手工編碼DAL/BLL /演示

我不認爲自己是任何方式的專家開發人員，但我確實瞭解常見的面向對象技術，並且可以完成我所有的項目。然而，我知道如何「建築」一個網站，但我很困難。那麼，我的意思是，我應該使用 n-tier architecture？這仍然是黃金標準，上述工具只是利用這個概念？我非常確定，我希望在未來（或最終）發佈之前推遲使用MVC。

*****編輯：我已刪除，其具有更充分地理解問題的分離後用圖案（單，工廠）涉及的問題的部分。感謝所有那些迄今爲止已經回答過這個部分的人，但是我主要關注的是體系結構部分。*****

編輯＃2：我改變標題爲更多的是一個不可知論的問題實現這將適用於超過Web特定的體系結構。

問題：我採取的第一步哪些步驟，當我在一張空白的畫布（解決方案文件），在手我所有的預先寫好的文檔和系統要求的前已經坐了下來？我從哪裏去？

來源

2008-12-23 Kyle Ballard

順便說一下，你的問題表示幾乎任何類型的項目 - 無論是網頁，或WinForms的Web服務 - 和最好的答案也將表明，將適合任何項目:) – flesh 2008-12-23 16:53:48

一般的架構方法採取的要點 - 我已更改標籤和問題標題。 – 2008-12-23 17:03:14

我認爲你列出的每種方法都有其優點和缺點。您選擇哪一個將取決於個人偏好，團隊成員和項目類型的經驗 - Linq2Sql很適合快速啓動並運行，但可能不適合大型和/或複雜的企業項目..你可以在那裏做的最好的事情是嘗試一些，並瞭解它們。

至於模式，它們以經過驗證的方式幫助解決特定問題和循環問題。他們還幫助未編寫代碼的開發人員熟悉。如上所述，值得嘗試幾個來感受他們做什麼以及何時使用它們 - 但他們解決特定的編程問題而不是架構模式。

我的典型的工作進程中運行：

創建一個邏輯實體模型
爲實體模型
創建數據訪問代碼和業務創建數據存儲對象
創建邏輯/業務層
創建表示層

我通常會將數據訪問和業務對象，業務邏輯和演示（網站/ winforms）分割到他們自己的項目中，再加上我以後可能需要重新使用的任何項目也會在其自己的項目中進行。我也有一個包含通用擴展和接口的基礎項目，幾乎可以在我所做的每件事中重用。

在體系結構方面，我嘗試確保我的項目是鬆散耦合的，這樣您就可以輕鬆地從三層架構輕鬆移動到n層架構。鬆耦合還意味着您可以切換後備存儲，並且只需編寫一個新的數據訪問層，其中所有邏輯和表示代碼都保持不變。

我覺得不要太掛在與ň層是非常重要的 - 如果你在分開以後在多個層次適當延長你的系統的擔憂將不會是一個困難的工作。

來源

2008-12-23 16:28:15 flesh

我個人是n層架構的粉絲。當我開始時，我通常會爲Web應用程序創建兩個項目，這是第一個用於業務邏輯和數據庫訪問的項目，這是一個類庫項目。然後我爲實際網站添加一個Web應用程序項目。

我過去建，我使用的是利用了微軟的數據應用程序塊的所有數據訪問的數據訪問框架，而這正是我使用結構中的所有數據呼叫。

我曾在多次使用CodeSmith中或其他物品，但到目前爲止，我已經找到了更好的運氣，只是我自己的滾動代碼，我可以得到的數據進行更精細。如果我有時間研究其他ORM工具，我可能不需要擔心它...

我發現最好的方法通常是創建您的業務對象，數據驗證和所有「業務」件應用程序。然後在數據訪問部分進行編程，最後將所有內容與演示代碼放在一起。能夠做到這一點需要一定的紀律，但它確保您以可重用的方式構建事物，並取得了巨大的成功。

你引用的這本書也是一個很好的例子。

從評論

添加針對發佈的評論。通常在我的Business/Data類庫中，我將使用命名空間將邏輯從數據中分離出來。一些關鍵的事情在這裏完成。

我的數據的方法調用在範圍上裝配都是有限的，他們不是物品可以直接調用，這樣我執行通過業務邏輯都呈現呼叫者
所有數據訪問數據輸入和輸出是通過對象完成的，而不是數據集或任何其他變體
驗證後的業務方法將調用數據組件中的特定方法以獲取所需的信息。

來源

2008-12-23 16:24:16

如何從單個類庫中分離業務邏輯和DataAccess邏輯？您是否爲DAL創建基礎對象，然後從它們繼承BLL？ – 2008-12-23 16:34:26

爲您添加了一些細節！（評論不夠大） – 2008-12-23 16:39:54

完美，謝謝你的額外輸入。 – 2008-12-23 16:49:12

這樣一個廣泛（而且很好）的問題。深呼吸。

不要從設計模式拿走，但他們的戰術相比，架構的戰略。當然要學習它們，但這裏不是特別適合。

很多你的問題提的事情並不相互排斥，可以被認爲是對整個體系結構的特定部分的子戰略。我的個人喜好了巨大的變化隨着時間的推移和經驗，我仍然是完全天真一些有趣的技術，但FWIW我認爲只有一種架構的全局常量：

關注分離。

這個原則是你的「金標準」，我認爲，它通知這麼多好東西：通過合同，依賴注入，MVC，n層的單元測試，設計。我說第一步是理解SoC，第二步是在測試驅動開發的基礎上採取行動。我認爲的其他一切都有優點和缺點，但維護，概念和首先認識到問題帶來的體系結構的好處毫無疑問。

我的書籤文件夾是不是我還以爲是，但這些都是一些網上作品，其凝固在這個問題上我的意見：

編輯：你從哪裏開始的空白畫布？

添加選擇的單元測試庫，並勾畫出測試（又名事實）。

測試>設計>代碼>轉到1

來源

2008-12-23 16:36:46 annakata

我不會排除ASP.NET MVC。

候選版本是由於出在一月，和令人驚訝的這次微軟似乎以下RC的真正含義，除非任何顯示塞漏洞被發現，也將要進行的RTM版本。

Link

來源

2008-12-23 16:37:07 Paul

理想的.NET架構？

回答

相關問題