再谈三层架构（传参数、返回值）

      运用分层的思想来做东西，设计时往往没问题，但如果不是很熟悉它的思想，往往会在编码时不知不觉地破坏了它的设计架构，导致编码与设计不符。比如，层与层之间传递参数的问题（用实体还是简单数据类型）、各层向上的返回值问题（用实体对象还是DataTable、DataSet）。报表绑定要注意什么。

      下面就这几个问题（三层为例）进行讨论，核心思想是项目开发（编码）一定要符合项目设计。

传参数

      如果采用三层架构来做项目，那么我们必须时刻围绕面向对象思想和“三层架构”这个体系来编码，即要符合各层之间的引用关系。不能破坏它的架构体系（即不能破坏设计的各层之间的关系）。

      三层架构规定了三层之间是通过传递Model（实体）参数来进行交流的。这个架构中，外观上看，只有这四个包中类下的对象（简单的数据类型封装在对象内部），不存在其它的任何东西，所以说层与层之间的参数传递必须通过实体对象来完成。如果用简单的数据类型（传递实体类的某个属性）就破坏了三层架构的体系（体系中不存在那个东西）。

      传递实体，符合面向对象封装的原则,信息隐藏在类中 ，后期还便于扩展与维护。

      当然如果设计不是分层的话，平时的传递参数时，传实体与一般数据类型各有利弊。

返回值

      其实与上边是同一个问题，之前可能为了便于与控件绑定，在D层就返回DataTable或DateSet

这既违背了面向对象的思想，也背离了三层架构的设计思想。

      首先与上面同理，三层架构中只有四个包（UI、BLL、DAL、Model）中类下的对象（简单的数据类型封装在对象内部），不存在其它的任何东西，所以层与层之间不能通过DataTable或DateSet来交流；那样的话B层和U层也都会用到DataTable或DateSet，也就是说B层和U层已经直接和数据库有了关系。这些都背离了三层架构的设计思想。

      其次，返回DataTable或DateSet的话就会使得实体（Model）层没有了用。这本身就是实体该干的事。正确的做法应该将返回的东西封装在实体中，然后返回实体对象在实现各层之间的交流。

报表绑定

      我们用到报表时都习惯直接将数据库表绑定到VS报表，这样的话，我们必须要给出设计说明，因为这已经不符合我们上面设计的三层。而是用的U层与数据库直接交互，就可以如下画图另行说明：

 

      总结：分层思想强烈要求面向对象，如果一个项目绝大部分适合用某一个设计（例：上面的三层），而一小部分用另一个设计（例：上面的报表绑定）比较好，就可以同时采用这两种设计，但一定要对那一小部分采用的设计给出说明。即，任何情况下，项目开发（编码）一定要符合项目设计。