ASP.NET MVC经典项目ProDinner项目解析（1）

前面的话:

      由于最近在设计一款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

该类文件做了模型实体的定义，基本可以说与将要运用的数据库形成了完成的模型映射关系。

 public class Entity
2 {
3     public int Id { get; set; }
4 }
5 
6 public interface IDel
7 {
8     bool IsDeleted { get; set; }
9 }

Entity为所有模型的公共基类，这其实是非常好的设计思想，我想我们一般在做数据库表结构设计的时候,表与表都会有些共同的字段，如操作人，操作时间，操作机器，操作程序接入模块名。这里其实只是一个范例，根据各自的需要自己调整需要的类字段设计。

 1   public class DelEntity : Entity, IDel
 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 IRepo<T>
 {
 }

public interface IDelRepo<T>
{
}

public interface IUniRepo
{
}

观察每个接口的名字我们就会发现，这里基本是攘括了所有的数据操作方式和数据业务逻辑的函数原型，其后Service所有具体实现的实体数据操作都会基于这些接口

Security

 ---IFormsAuthentication.cs

定义用户登录的业务处理过程。同样也是抽象的规范接口。

Service

 ---ICrudService.cs

该层定义了一些业务操作得的函数接口，如果说IRepo是标准的接口规范，那么ICrudService就是个性化定制接口最后ProDinnerException.cs定义

项目自身的异常处理类，如果要建立自己的异常规范文档，那么像这样来处理异常显然是不可以的，我们可以看看国产化的淘宝接口，每个异常对应着编号，

以及自身的异常描述。我的建议是依据程序和模块来处理异常。这样形成完整的层次关系。Core层暂时解析这么多。