[转载]ASP.NET MVC经典项目ProDinner项目解析（1）

[转载]ASP.NET MVC经典项目ProDinner项目解析（1） – aspnetdream – 博客园.

前面的话:

由于最近在设计一款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
{
public int Id { get; set; }
}

public interface IDel
{
bool IsDeleted { get; set; }
}

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

public class DelEntity : Entity, IDel
     {
         public bool IsDeleted { get; set; }
     }
 
     public class Country : DelEntity
     {
         public string Name { get; set; }
     }
 
     public class Meal : DelEntity
     {
         public string Name { get; set; }
         public string Comments { get; set; }
         public virtual ICollection<Dinner> Dinners { get; set; }
         public string Picture { get; set; }
     }
 
     public class Chef : DelEntity
     {
         public string FirstName { get; set; }
         public string LastName { get; set; }
         public int CountryId { get; set; }
         public virtual Country Country { get; set; }
     }
 
     public class Dinner : DelEntity
     {
         public string Name { get; set; }
         public int CountryId { get; set; }
         public virtual Country Country { get; set; }
         public int ChefId { get; set; }
         public virtual Chef Chef { get; set; }
         public string Address { get; set; }
         public DateTime Start { get; set; }
         public DateTime End { get; set; }
         public virtual ICollection<Meal> Meals { get; set; }
     }
 
     public class User : DelEntity
     {
         public string Login { get; set; }
         public string Password { get; set; }
         public virtual ICollection<Role> Roles { get; set; }
     }
 
     public class Role : Entity
     {
         public string Name { get; set; }
         public virtual ICollection<User> Users { get; set; }
     }

接下来其实就没什么特别的，建立程序需要使用的业务类，这个时候其实针对于Code First而言，还不存在数据库这个概念，只是根据我们的业务需要设计相应的模

类在涉及到表关联的时候，我们看到，这里统一使用了ICollection的集合，并且都是Virtual类型，这非常明确的表示了该层都是接口和基类，注定是要被重写。这里稍微提下，如果需要再抽象点，再低耦合点，那么我想再定义一个ICollection，而不是具体指定那个类，这样就更抽象了。

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层暂时解析这么多。