[转载]看了一些ASP.NET MVC开源项目后的一些想法,关于ASP.NET MVC+Repository+Service架构的一些思考

baacloud免费翻墙vpn注册使用

[转载]看了一些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。如:

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开源项目的一点小小的思考,欢迎大家批评指正。

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

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

支付宝扫一扫打赏

微信扫一扫打赏