关于三层结构实现之疑问
在网上也找不了少的资料来看，如PetShop也下载来学习，但是结合到实际的开发中，却还是有不少疑问。
如：
DAL：数据库访问层，进行数据库访问，把数据填充入相应Model
BLL：业务逻辑层，调用DAL，处理程序业务逻辑
UI：界面层，将数据绑定到界面，调用BLL
Model：数据实体类

每个表或者说是针对表的业务，都被封装起来了。如果我在界面层需要的数据必须通过视图才能展现，那么理论上是在DAL就应该有针对的封装还是把这个封装放置在BLL上？另外，如果UI上有一些小的变更，比如说要多看到一个字段的数据，那么就要从BLL甚至从DAL上去修改，这样多层结构的松耦合体现在那里呢？同理，为了上述的修改变更，必须反过来设计，即先确定UI上要展现那么数据，然后确定BLL层提供的业务，再确定DAL提供的数据，这样的设计顺序是正常的吗？请各位前辈出来指点一下迷津吧。

------解决方案--------------------
其实矛盾出现在 UI需要的是 Business Model，而Bll和Dal 针对的是 DataBase Entity。
一个完整的业务，是由多个实体对象构建了一个业务对象。如果用失血模型解决这类问题，的确会出现 “如果UI上有一些小的变更，比如说要多看到一个字段的数据，那么就要从BLL甚至从DAL上去修改”； 如果实体对象是充血模型，这样又会带来网络传输等诸多问题。那么这个时候，会考虑用贫血模型
贫血模型类似于数据库中的View ，它本身带有对象间的关系，但是提取的是依赖对象中，需要的属性作为本身的展示属性，这些属性只会参与 对象操作的Query动作（ORM中的查询操作）。同时也可以解决 在UI需要增加字段，只会修改UI和数据实体的定义上

说的不好，请见谅。
------解决方案--------------------
一个UI对象往往对应3个以上甚至几十个BLL对象，把这个“开放”地去考虑，不要竖井地认为只能有一个，并且不要去继承地实现它。