MVC与三层架构的区别

转载：http://blog.csdn.net/csh624366188/article/details/7183872

1.本质上都是低耦合。

2.三层架构（数据访问层，业务逻辑层，表现层）中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。

3.MVC中的model可以创建成数据访问层，业务逻辑层。

4.转自 http://www.cnblogs.com/jiagoushi/archive/2013/04/03/2998795.html

首先应用程序启动的是客户端代理层，这是我从来没有想到过的开发方式，通过代理层将UI层的界面以插件的形式进行加载，UI层相关的业务逻辑会调用客户端逻辑层，客户端逻辑层会通过.Net Remoting技术高效的调用服务层的方法，服务层通过DAL层进行增删改查操作，当然客户端与服务端的数据传输是通过DTO层进行的。

其中ORM层不是我原来认为的会通过ORM工具进行，而是数据实体层，可能是我没有看到里面具体的实现代码的原因，但是我看到的是ORM层是大量的数据实体，DTO层就是要传输的数据对象。她们会通过接口层进行方法的匹配调用。

通过这个项目，我不是说让我们了解到或者说学习到什么，我只是想说难怪每个程序员都不一样，设计出来的项目结构有时候也需要我们参考。原来多学习别人的设计可以带来这么多的用途。丰富自己的见解，能让自己耳目一新的感觉。

好了，不说废话了，我来说一下我通过这个结构学习到了什么？

首先就是客户端代理层，将UI以插件的方式进行加载，我个人认为这是个很不错的方法，代理层决定要加载哪些内容，而不是我们在界面上全部设计好，可以让代理层自己组装。

其次让我意外的就是数据传输层DTO的使用，说实话我一直就了解DTo的用途，但是我从来都没有想到过在实际的项目中要用到他。DTO和数据实体有一些区别。我在实际项目中一般都是传输数据实体，把数据库表对应的数据实体进行传输，当然我见到很多人都这样做，简单快捷，但是我今天看到了DTO层的单独使用，让我明白以后在追求好的解决方案的时候，开发上的快捷有时候会带来性能上的开销。我理解中的DTo应该是包括要传输的数据，但是可能包括一个表中的一个字段和另一个表的两个字段，这样通过DTo层可以很容易的实现，但是通过数据实体我们就需要传输两个对象，会无形中增加数据的开销。

 

5.转自：http://www.cnblogs.com/legendxian/archive/2012/06/18/2553111.html#2408470

           架子设计