前面的話:
由於最近在設計一款Web產品，我希望找到一成熟的耦合度低的產品架構，並且是建立在asp.net mvc的框架基礎上的，對此找到ProDinner開源項目，但是網上的資料少得可憐，好，沒有范例，那么就自己來做處理，所以將自己的所學與各位分享，多有不足，就算是拋磚引玉，望高手指點。
一、整體系統分析
系統采用了Entity Framework Code First+Asp.NET MVC Razor+Castle.Core+Castle.Windsor，可以說整體設計是個非常輕量級別的框架，但卻是做到了或者說慣承了整體架構分層明顯，模塊耦合度低的架構思想。
Core層實現了本地化Models和Entity Fremework模型化需要的models數據，另該層的另一個職能是，為低耦合的業務邏輯和低耦合的數據訪問做好了接口准備，所以我說這個項目慣撤了低耦合的架構思想，如果要設計一個更大型的項目，那么這層可以繼續將業務邏輯和數據訪問，以及一些公共運用的功能進行更近一層的接口化。
Model
---DelEntity.cs
該類文件做了模型實體的定義，基本可以說與將要運用的數據庫形成了完成的模型映射關系。
2 {
3 public int Id { get; set; }
4 }
5
6 public interface IDel
7 {
8 bool IsDeleted { get; set; }
9 }
Entity為所有模型的公共基類，這其實是非常好的設計思想，我想我們一般在做數據庫表結構設計的時候,表與表都會有些共同的字段，如操作人，操作時間，操作機器，操作程序接入模塊名。這里其實只是一個范例，根據各自的需要自己調整需要的類字段設計。
2 {
3 public bool IsDeleted { get; set; }
4 }
5
6 public class Country : DelEntity
7 {
8 public string Name { get; set; }
9 }
10
11 public class Meal : DelEntity
12 {
13 public string Name { get; set; }
14 public string Comments { get; set; }
15 public virtual ICollection<Dinner> Dinners { get; set; }
16 public string Picture { get; set; }
17 }
18
19 public class Chef : DelEntity
20 {
21 public string FirstName { get; set; }
22 public string LastName { get; set; }
23 public int CountryId { get; set; }
24 public virtual Country Country { get; set; }
25 }
26
27 public class Dinner : DelEntity
28 {
29 public string Name { get; set; }
30 public int CountryId { get; set; }
31 public virtual Country Country { get; set; }
32 public int ChefId { get; set; }
33 public virtual Chef Chef { get; set; }
34 public string Address { get; set; }
35 public DateTime Start { get; set; }
36 public DateTime End { get; set; }
37 public virtual ICollection<Meal> Meals { get; set; }
38 }
39
40 public class User : DelEntity
41 {
42 public string Login { get; set; }
43 public string Password { get; set; }
44 public virtual ICollection<Role> Roles { get; set; }
45 }
46
47 public class Role : Entity
48 {
49 public string Name { get; set; }
50 public virtual ICollection<User> Users { get; set; }
51 }
接下來其實就沒什么特別的，建立程序需要使用的業務類，這個時候其實針對於Code First而言，還不存在數據庫這個概念，只是根據我們的業務需要設計相應的模
類在涉及到表關聯的時候，我們看到，這里統一使用了ICollection<T>的集合，並且都是Virtual類型，這非常明確的表示了該層都是接口和基類，注定是要被重寫。這里稍微提下，如果需要再抽象點，再低耦合點，那么我想再定義一個ICollection<T>，而不是具體指定那個類，這樣就更抽象了。
Repository
---IRepo.cs
顧名思義，這是一個倉庫，業務操作的倉庫，我們更多的聽到的是數據倉庫，那確有操作倉庫。
{
}
public interface IDelRepo<T>
{
}
public interface IUniRepo
{
}
觀察每個接口的名字我們就會發現，這里基本是攘括了所有的數據操作方式和數據業務邏輯的函數原型，其后Service所有具體實現的實體數據操作都會基於這些接口
Security
---IFormsAuthentication.cs
定義用戶登錄的業務處理過程。同樣也是抽象的規范接口。
Service
---ICrudService.cs
該層定義了一些業務操作得的函數接口，如果說IRepo是標准的接口規范，那么ICrudService就是個性化定制接口最后ProDinnerException.cs定義
項目自身的異常處理類，如果要建立自己的異常規范文檔，那么像這樣來處理異常顯然是不可以的，我們可以看看國產化的淘寶接口，每個異常對應着編號，
以及自身的異常描述。我的建議是依據程序和模塊來處理異常。這樣形成完整的層次關系。Core層暫時解析這么多。