项目经理王涛和架构师李帅在技术路线上产生了分歧，这不是什么好事，对项目来说。所以有必要进一步把三层架构的问题讨论清楚，否则这个项目无法进行下去。

三层架构有数据访问层、业务逻辑层和表示层。实际上还有数据这一层，一般而言数据是存储在数据库中，是我们程序要操作的对象，所以在程序中并不体现数据这一层，从程序的角度看还是三层。

先说一下数据访问层，其功能是对数据库中表的数据进行操作，表现为增、删、查、改。为了实现这些功能，需要在程序中创造相应的对象，最常见的方式是建立一组与数据库表相对应的类，这些类是数据访问层需要操作的对象。这些数据类的集合称之为数据对象模型。在我们的开发中会把这些类归集到一个Domain中。我们再看看数据访问层的这些代码怎么处理。这些代码都是处理与数据库相关的功能，主要都是一些函数，这些函数也需要归集到一个类中，这个类几乎没有什么自己的属性，下面的函数也都是静态函数，有时候我们也称之为静态类。这些函数的功能是把数据对象的数据存储到数据库表中或者从数据库表中读取数据加载到数据对象中。

表示层是表现在用户面前的页面或界面。界面是最容易发生变化的。在.net的Web开发中，页面主要是asp.net编程，aspx页面，页面下的C#程序处理对页面的响应。

业务逻辑层主要是实现业务功能的，是为表示层服务的，它需要数据访问层为其建立其与数据库的通路。业务逻辑层的功能与表示层的关系非常大，表示层发生了变化，业务层也会跟着进行调整。

在三层架构中，业务层是最难设计的，抽象对象也是最难的，所以业务层的类是最混乱的，每一个程序员根据表示层的需要就会随意增加一个类或方法，出现很多方法功能类似的情况，这样代码就会很多，出错的概率也会很大。而且会随着系统上线，维护量越来越大，直到无以负荷。

根本的原因还是三层架构的设计思想是面向功能的而不是面向对象的，虽然代码都是写在类里。功能的变化对结构的影响是巨大的，而在系统中，变化最大最多的就是功能，这些功能不会随着系统的上线而终结，而会变得越来越多。