多层构架通俗一点说就是把一个项目在纵向分成多个层次，每一个层次有自己的指责。高内聚低耦合是系统设计的原则，高内聚指层有一个明确的指责，把和自己指责有关的东西封装在层内部，不对外暴露；低耦合指层与层之间相对联系不要过于紧密，特别要注意不能跨层通讯。举例来说，假设我们把一个系统分成表现层、业务逻辑层和数据访问层（这就是最流行的三层构架）。首先定义各个层的指责：
    表现层：把业务逻辑层返回的数据按照一定的格式显示在页面上，根据用户的操作调用业务逻辑层的相关方法；
    业务逻辑层：进行业务相关的处理，如果需要访问数据库操作就调用数据层。
    数据访问层：进行数据访问操作。
根据高内聚原则，我们需要避免下述情况的产生：
    做不属于当前层指责的事情。比如，在业务逻辑层访问数据库进行数据访问操作的情况不应该发生。也就是说，在业务逻辑层不应该看到任何和数据访问相关的东西（比如SQL语句、SqlCommand对象）
    把不必要的信息返回给上层。比如，我们不应该在业务逻辑层把数据访问层中的某一个错误返回给表现层，表现层是不可能也不需要理解一个和数据库相关的错误的（返回“新增用户失败”的信息比返回“当前记录的主键发生重复”这样的信息好很多）。
根据低耦合的原则，我们可以尽量采取下面的措施：
    层之间通过接口调用。比如，实现定义一个数据访问的接口，数据访问层实现这个接口，这样即使我们需要根据数据访问层的实现（比如换数据库）也不需要更改业务逻辑层的代码（因为接口是不变的）。
    避免跨层调用。比如，表现层只应该调用业务逻辑层而不应该直接调用数据访问层。
读者可能会问，为什么要分层？分层会增加不少代码，增加系统的复杂性，不分层的代码照样可以工作得很好啊。的确是这样，就像第一节中说的误区那样，很多人不明不白就按照别人的做法为自己的项目分层。如果您的项目确实不需要分层，或者您根本不明白分层的意义，那么您的分层最终也是无意义的，或者说就算分层了也没有达到分层的意义。
    分层的意义何在？
举两个例子。1、如果您把业务逻辑和数据访问写在aspx文件的cs代码中，系统实现了所有的功能。突然有一天老板说，我们这个东西要做成Windows程序了，那么整个一个程序就没有用了。如果当时您把业务和表现分开，现在可能只需要新建一个Windows程序，调用原来的业务层即可。2、在经历过前一个项目后您终于决定以后的项目都把表现和业务分开，不管表现层是网站还是Windows程序，都能轻松应付。突然又有一天老板决定把数据库从SQLSERVER迁移到ORACLE，可能对于您来说又是一个晴天霹雳，需要把所有的程序重写。如果当时您把数据访问操作和业务逻辑层分离出来，那么现在可能您只需要修改这一个数据访问层就可以了（因为所有的程序都调用同样一个数据访问层）。
注意：这里说的数据访问层是仅仅处理数据操作的，没有任何和业务相关的东西，所有程序都调用相同的数据访问层。
    分层是不是越多越好？
当然不是，我们应该按照下面的思路思考怎么分层。默认认为程序是不需要任何分层，哪个地方可能会发生改动或者需要重用再考虑分层，由少到多，而不是盲目地说我的程序要分5层要分6层。
    分层后程序的性能会不会降低？
分层肯定是有性能降低的，但是分层后整个程序的灵活性会高很多，您可以权衡而定。
    分层后程序维护起来不是很麻烦吗？
很多人有这个困惑，分层后一旦要修改一个数据库字段需要把所有的层都修改一遍。往往这是由于你的指责不明确引起的。假如您的数据访问层仅仅做的是对某种数据库的数据访问操作，不涉及任何的业务，那么即使修改了表结构，数据访问层不需要修改任何代码。加入您的表现层仅仅是根据业务模型呈现数据，即使我们把字段名从Username修改成了name，由于业务层返回的还是原来的业务实体，表现层也不需要做任何改动。反之，您直接把从数据库中SELECT的记录通过DataSet返回给表现层，那么修改了数据表字段后肯定也要修改表现层。