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

baacloud免费翻墙vpn注册使用

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

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏