大家一般怎么分层设计的
我现在设计的系统也是3层结构，页面层和业务逻辑层没什么说的，但是对于数据层做了抽象，业务逻辑层不直接依赖于具体的数据层，而是依赖于数据层的抽象IDataLayer,数据层的具体实现是用Linq来完成的(考虑到也可以用其他的比如SqlServer的或Oracle，扩展起来比较方便)，有专门的业务逻辑层的对象，具体的数据层实现会返回业务逻辑对象。业务逻辑层通过工厂模式得到数据层对象。
具体如下：
比如IDataLayer层有个IEmployeer接口，然后Linq层有个Employeer类继承IEmployeer，逻辑层有个EmployeerInfo类(是业务实体类，只有属性),Employeer的方法会返回EmployeerInfo对象。工厂方法IDataFactory类通过反射加载Linq层的程序集，并创建返回Employeer对象，然后业务逻辑层调工厂类。

这样存在的问题是，每次数据层都要去组装好业务逻辑层的对象，然后返回供上层使用，或者上层丢给数据层一个对象，拆了后再存储或修改，系统很小，业务逻辑也没什么内容，这样做是不是反而影响效率，太牵强了？


------解决方案--------------------
分层架构确实对效率造成一定的影响，分层次的目的即为了能够体现软件工程里面“高内聚，低耦合”的思想。
优点是：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以用新的实现来替换原有层次的实现；
3、有利于标准化；
4、利于各层次之间的逻辑复用。

缺点是：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、修改代码的时候会导致级联修改。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

------解决方案--------------------
Patterns of Enterprise Application Architecture
企业应用架构模式

有时间读读书吧，里面解释得很清楚！
------解决方案--------------------
你的这个设计不好,特别是工厂方法IDataFactory类通过反射加载Linq层的程序集，并创建返回Employeer对象，然后业务逻辑层调工厂类的方式。

实际上，业务逻辑一定依赖于业务实体的具体属性，很少会发生实体变更后业务逻辑不发生变化的情况。即便，业务实体需要发生改变，也不会采用仅仅替换数据实体层的方式，要么使用扩展属性，要么使用更复杂的含有元数据的系统。这样的设计毫无必要。通常实体模型单独隔离是为了接口标准的需要，而不是为了灵活性。

要实现足够的灵活性，这种分层设计是做不到的


------解决方案--------------------
个人认为，分布分层该根据需求而来。DDD强调需求先行，并以通用语言交流为基础。因此，如果楼主只是做个小东西，没必要搞得那么兴师动众。更进一步，如果经过分析，发现在软件的有生之年，其所使用的数据库或者存取方式不会发生变化，那你在这里加入DAL、IDAL岂不是多余。
领域模型对象（实体、值对象和服务）位于领域层，也就是业务层，在作数据展现的时候，可以通过数据传输对象（DTO）进行。数据传输对象是领域对象的数值体现，本意是用来一次打包数据以减少网络程序中服务器与客户机的数据传输来回次数，在DDD中，可以看成是对领域对象的一种封装，即仅向上层公布数值，而不公布业务逻辑。假设将领域对象暴露给其他层，这就变成了其他层可以直接访问业务层中的东西，这并不是一件好事。因此，DTO的引入是有必要的。
对于领域对象的状态持久化，我还是比较看好repository模式的，它把问题简化了：repository负责存储、检索、重建领域对象，这让人很自然地了解到领域对象不仅仅需要处理业务逻辑，而且还会保持着自己的状态，不仅如此，repository如何保存领域对象，将其保存到哪里，领域对象本身甚至是业务逻辑层都不会去关心，这就解耦了业务层和基础结构层。