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
该类文件做了模型实体的定义，基本可以说与将要运用的数据库形成了完成的模型映射关系。
1 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层暂时解析这么多。