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 { getset; }
4 }
5 
6 public interface IDel
7 {
8     bool IsDeleted { getset; }
9 }

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

 

 1   public class DelEntity : Entity, IDel
 2     {
 3         public bool IsDeleted { getset; }
 4     }
 5 
 6     public class Country : DelEntity
 7     {
 8         public string Name { getset; }
 9     }
10 
11     public class Meal : DelEntity
12     {
13         public string Name { getset; }
14         public string Comments { getset; }
15         public virtual ICollection<Dinner> Dinners { getset; }
16         public string Picture { getset; }
17     }
18 
19     public class Chef : DelEntity
20     {
21         public string FirstName { getset; }
22         public string LastName { getset; }
23         public int CountryId { getset; }
24         public virtual Country Country { getset; }
25     }
26 
27     public class Dinner : DelEntity
28     {
29         public string Name { getset; }
30         public int CountryId { getset; }
31         public virtual Country Country { getset; }
32         public int ChefId { getset; }
33         public virtual Chef Chef { getset; }
34         public string Address { getset; }
35         public DateTime Start { getset; }
36         public DateTime End { getset; }
37         public virtual ICollection<Meal> Meals { getset; }
38     }
39 
40     public class User : DelEntity
41     {
42         public string Login { getset; }
43         public string Password { getset; }
44         public virtual ICollection<Role> Roles { getset; }
45     }
46 
47     public class Role : Entity
48     {
49         public string Name { getset; }
50         public virtual ICollection<User> Users { getset; }
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层暂时解析这么多。
 
 
 
 
 
 
 
 
 
posted @ 2012-03-02 21:52  aspnetdream  阅读(5305)  评论(13编辑  收藏  举报