分享一个Mvc的多层架构

不管DDD也好，CQRS也好，其实这两种都不会100%适合所有的项目架构的，这就需要架构师结合项目本身特点及需求有所选择，但是其中的思想我们可以运用在项目的任何地方。

基于消息的分布式：

其实不管使用怎样的架构，加入怎样的架构思想（soa），核心或者是开发者最想达到的就是层次，系统之间的解耦，复杂的东西没人会喜欢。

随着系统的发展，我们的程序会涉及到多台服务器，多种终端，同时为了解耦我们引入了基于消息的分布式架构。

首先，所以系统的通信基于消息，逻辑联系不会涉及到具体的业务实现，同时消息的传递更加的廉价可适配多种终端。

其次，由于所用逻辑只是基于消息实现，迭代的成本也会相对于其他耦合项目更快更方便。

展示层：

随之Web2.0的到来单一页面展示的信息也更加的丰富，Ajax，js的流行也使得Ui端的操作也愈加变重，于是大家有期望以一种工程的思想去拥 抱这种变化，于是MVVM，js的Mvc框架陆续出现。同时随着移动互联网的兴起，不同终端对于系统的对接也非常重要，于是我们考虑在Ui与Logic之 间引入Application或Service层应对不同终端配置。

如：我们在Client Presenter Layer 上加入WCF适配多种终端提交的订单，都是建立在消息基础之上的，楼主之前做电商系统是针对于来自淘宝，天猫，亚马逊订单时，为避免出现对库中订单并发， 产生“超买”情况，采用了在上层Ui与logic层之间引入了OrderChannel层，将不同终端订单进行排队的解决方案。

以上是架设一个能够适配不同需求的架构过程，但是真正的真理是需要大家在实践中，错误中汲取的。

下面是楼主简单的小分层架构，不妥，不足之处希望大家指导斧正。

层次划分：

为了实现单独部署，层次解耦所以层次之间是基于接口实现的。

DataAccess层引入仓储实现统一DTO操作，实现基于Ef：

IRepository：

1. 2. 3. 4. 5. 6. 7.

public interface IRepository where T:class {

IEnumerable FindAll(Expression> exp); void Add(T entity); void Delete(T entity); void Submit(); }

引入RepositoryBase实现接口定义：

1. 2. 3. 4. 5. 6.

public class RepositoryBase:IRepository where T:class {

DbContext context;

public RepositoryBase(DbContext _context) {

context = _context;

7. 8. 9.

}

public RepositoryBase() {

10. this.context = new TestDBEntities(); 11. } 12.

13. public IEnumerable FindAll(Expression> exp) 14. {

15. return context.Set().Where(exp); 16. } 17.

18. public void Add(T entity) 19. {

20. context.Set().Add(entity); 21. } 22.

23. public void Delete(T entity) 24. {

25. context.Set().Remove(entity); 26. } 27.

28. public void Submit() 29. {

30. context.SaveChanges(); 31. } 32. }

这对于单一的某个仓储我们单独引入其自身的仓储接口：

1. 2. 3. 4. 5. 6.

public interface IUserRepository:IRepository {

IList GetAllById(int id);

bool CheckUserExist(UserTest u); }

特定仓储实现：

1. 2. 3. 4. 5. 6. 7.

public class UserRepository : RepositoryBase,IUserRepository {

public IList GetAllById(int id) {

using (TestDBEntities entities=new TestDBEntities()) {

var users = from u in entities.UserTests