Mikel
[转载]看了一些ASP.NET MVC开源项目后的一些想法，关于ASP.NET MVC+Repository+Service架构的一些思考 – 专注于ASP.NET技术 – 博客园.
最近在学习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。如：
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开源项目的一点小小的思考，欢迎大家批评指正。
