MVC和三层架构
首先、它们很相似；MVC可分为：Model模型层、View视图层、Controller控制层；三层架构为：视图层、控制层、业务逻辑层+ 数据访问层。

如此分包法，层次上的结构虽清晰，而且很大程度地减少了模块之间的耦合度，但这样同时也添加了些许麻烦。

小的项目这样分层，分包，不太符合实际；但对于大中型项目这样的分工是太有必要了，视图层、控制层、业务逻辑层、数据访问层，目前我们只要知道这是最合理的分层模式就可以了。

架构中，我们可以如此分布：
控制层+（（模型层+ 数据访问层）+ 视图层）= 合理架构。

数据模型层
顾名思义，用来和数据库进行连接交互，SQL语句当然应该置于此。

模型层中数据访问模块的功能如下：
1)实现数据的读取与存储操作。

2)实现事务处理。

界面视图层
主要是处理和用户进行交互的界面，显示结果或者接受输入。

视图层中用户界面模块的功能如下：
1)与用户的交互，接收用户的各种输入以及输出各种提示信息或处理结果。

2)对于输入的数据进行数据校验，过滤非法数据。

3)向业务层发送处理请求。

业务控制层
进行各种逻辑判断。

也就是业务逻辑的封装，如有一客户要下一个用账户付款的订单，但该客户账户内的余额不够，则不该允许此客户下订单，这种逻辑就应放在业务层。

业务层中业务处理模块的功能如下：
1)实现各种业务处理逻辑或处理算法。

2)验证请求者的权限。

3)向数据层发送数据操作的请求。

4)向用户层返回处理结果。

针对每一层可以设计一个或多个模块，每个模块完成相对独立的功能。

逻辑架构总结
逻辑架构定义了如何分离应用程序中不同的代码。

一个好的逻辑架构的目的是使代码更容易维护、理解和可重用性。

而物理架构的定义则指定了运行应用程序的电脑，一个好的物理架构目的在于使系统在性能、可扩展性、安全性和容错能力之间取得最好的平衡，来满足你的特定环境。

分层架构的主要优点是分化了系统的复杂度，同时也提高了系统的灵活性（这点从系统同时满足各种类型数据库即可看出），另外，分层架构大大提高了系统的可维护性和可扩展性。

但是，分层架构在众多优点的背后也隐藏着缺点，由于层次的增多，同一个解决方案下项目也多，过多的跨项目访问对应用程序的效率有一定的影响，但这一点现在可以在越来越快的硬件提升速度中忽略。