『飞秋』关于ASP.NET MVC+Repository+Service架构的一些思考

『飞秋』关于ASP.NET MVC+Repository+Service架构的一些思考

看了一些ASP.NET MVC开源项目后的一些想法，关于ASP.NET MVC+Repository+Service架构的一些思考
最近在学习ASP.NET MVC 2.0的一些开源项目，发现这些项目中都普遍用到了同一种架构设计，即：

ASP.NET MVC + Service + Repository。从网上看了一些关于这方面的介绍后觉得这种架构确实满好的。以微软的一个典型的开源项目Oxite为例：

该项目由下面的Projects组成：

1）Oxite;

2）Oxite.LinqtoSqlDataProvider;

3）Oxite.Mvc;

4）Oxite.Mvc.Tests;

5）OxiteSite；

 

Oxite Project：

1）定义所有项目中需要用到的Model，即Entity，并且所有的Model都是纯Model，它们不依赖于任何ORM框架相关的信息。Model的作用是作为数据在UI层、业务逻辑层、数据访问层之间传递；

2）定义Repository接口。Repository和通常三层架构中的数据库访问层（DAL）从形式和功能上看差不多，个人感觉区别两者在意图上有所不同。
Repository是DDD（Domain-Driven Design 领域驱动模型 ）中的概念，强调Repository是受Domain驱动的，Repository中定义的功能要体现Domain的意图和约束，而DAL更纯粹的就是提供数据访问的功能，并不严格受限于Business层。Repository所提供的一切接口都应该是业务逻辑层所需要的，如果业务逻辑不需要的，它就不必提供。但是最近看到网上有一些朋友实现了一些泛型的Repository接口，个人认为不是很好。因为这违背了我们设计Repository的初衷，Repository接口是提供给Domain层的操作契约，不同的Entity对于Domain来说可能有不同的操作约束，比如User可能不应该被删除，BookOrder可能不应该被修改，也就是说Domain层根本就不应该能调用_repository<User>.Delete(user)，_repository<BookOrder>.Update(BookOrder)这样的操作。因此，Repository接口还是应该单独针对每个Entity类来定义。

3）定义和实现Service层。

Servide层定义和实现了整个应用程序的所有业务逻辑。Service利用Repository接口来完成数据库操作。每个Service接口除了利用Repository来操作数据库之外，还会做很多额外的事情，如数据验证等。

 

Oxite.LinqtoSqlDataProvider Project：

该项目是用 Linq to Sql ORM 技术实现的一个具体的 DataProvider（Repository）。该项目中会定义一些Linq to Sql ORM框架相关的Entities，借助于LINQ强大的语法功能，我们可以很方便的把这些Entities转换为Oxite中定义的Entity。如：

 1 public User GetUser(string name)
 2 {
 3     return (from u in context.oxite_Users
 4             where string.Compare(u.Username, name, true) == 0
 5             select new User()
 6             {
 7                 ID = u.UserID,
 8                 Name = u.Username,
 9                 DisplayName = u.DisplayName,
10                 Email = u.Email,
11                 HashedEmail = u.HashedEmail,
12                 Password = u.Password,
13                 PasswordSalt = u.PasswordSalt,
14                 Status = u.Status
15             }).FirstOrDefault();
16 }
 

 

oxite_User是Linq to Sql ORM框架所生成的Entity，User就是Oxite Model中定义的Entity。

 

Oxite.Mvc Project：

该项目包含了所有的Controller，但不包含View；Controller负责利用Service层来为View提供服务。一般来说，只要是和ASP.NET MVC相关的技术，都不应该放在Service层中实现，而应该放在Controller中实现。这样可以确保Service层可以被非ASP.NET MVC技术的程序所重用。

 

OxiteSite Project：

该项目就是一个普通的ASP.NET MVC Website，但它仅仅包含了一些View以及js和css等。

 

总结：

上面的架构设计我觉得有以下三个好处：

1）Oxite project实际上已经完整的代表了的应用了。因为一个应用由UI、Business、Data三部分组成。而这个project包含了Business和Data，当然，应该说它包含了对整个应用程序的业务逻辑的描述，并没有包含具体的业务逻辑实现，具体的业务逻辑的数据持久化实现是通过Oxite.LinqtoSqlDataProvider这个项目实现的。但这并不影响我们把Oxite理解为整个应用的主体。所以我想这个项目就是ASP.NET MVC架构中的Model吧。

2）利用Repository模式，完全把应用程序的业务逻辑和数据持久化工作分离。所以我们完全可以编写很多不同的ORM框架来完成数据的持久化工作。我们唯一需要配置的就是在web.config文件中设置该使用哪一个DataProvider；当然，就Oxite这个开源项目而言，在Oxite.LinqtoSqlDataProvider中单独定义了另外一套Entity，导致我们在查询数据时必须要做一个Entity的转换。这一点也许是我觉得有点不好的地方吧。当然其实Linq to Sql是支持xml来配置ORM映射关系的。所以理论上应该支持不用另外定义一套Entity。

3）前台利用ASP.NET MVC技术实现，并且把Controller和View分离在不同的项目中实现。个人觉得主要的考虑是为了更好的团队开发。让开发View的人专注于设计View，而让Controller开发人员专注于View和Model之间的控制协调。

 

所以，可以设想，如果基于这样的架构开发一个应用，个人觉得可以先开发好Model，然后再开发一个或几个DataProvider来实现Model中定义的Business，然后可以写一个Test工程来测试这个Model，等Model稳定后，再去开发View和Controller。

 

以上是我对我最近看的一些ASP.NET MVC开源项目的一点小小的思考，欢迎大家批评指正。
飞秋官网：http://www.freeeim.com/