具体如下：
比如IDataLayer层有个IEmployeer接口，然后Linq层有个Employeer类继承IEmployeer，逻辑层有个EmployeerInfo类(是业务实体类，只有属性),Employeer的方法会返回EmployeerInfo对象。工厂方法IDataFactory类通过反射加载Linq层的程序集，并创建返回Employeer对象，然后业务逻辑层调工厂类。
这样存在的问题是，每次数据层都要去组装好业务逻辑层的对象，然后返回供上层使用，或者上层丢给数据层一个对象，拆了后再存储或修改，系统很小，业务逻辑也没什么内容，这样做是不是反而影响效率，太牵强了？
16 个解决方案
#1
分层架构确实对效率造成一定的影响，分层次的目的即为了能够体现软件工程里面“高内聚，低耦合”的思想。
优点是：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以用新的实现来替换原有层次的实现；
3、有利于标准化；
4、利于各层次之间的逻辑复用。
缺点是：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、修改代码的时候会导致级联修改。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
优点是：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以用新的实现来替换原有层次的实现；
3、有利于标准化；
4、利于各层次之间的逻辑复用。
缺点是：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、修改代码的时候会导致级联修改。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
#2
ding !
#3
不要为了分层而分层，建一座茅房不需要设计师
#4
Patterns of Enterprise Application Architecture
企业应用架构模式
有时间读读书吧，里面解释得很清楚！
企业应用架构模式
有时间读读书吧，里面解释得很清楚！
#5
避免过度设计，那样做不出东西
#6
实事而论，要看是否有价值
#7
一般 5~6层 可参照 微软的petShop宠物商店
#8
受益
#9
系统小就直接敲代码吧，或者2层足以
#10
学习
#11
你的这个设计不好,特别是
工厂方法IDataFactory类通过反射加载Linq层的程序集，并创建返回Employeer对象，然后业务逻辑层调工厂类的方式。
实际上，业务逻辑一定依赖于业务实体的具体属性，很少会发生实体变更后业务逻辑不发生变化的情况。即便，业务实体需要发生改变，也不会采用仅仅替换数据实体层的方式，要么使用扩展属性，要么使用更复杂的含有元数据的系统。这样的设计毫无必要。通常实体模型单独隔离是为了接口标准的需要，而不是为了灵活性。
要实现足够的灵活性，这种分层设计是做不到的
实际上，业务逻辑一定依赖于业务实体的具体属性，很少会发生实体变更后业务逻辑不发生变化的情况。即便，业务实体需要发生改变，也不会采用仅仅替换数据实体层的方式，要么使用扩展属性，要么使用更复杂的含有元数据的系统。这样的设计毫无必要。通常实体模型单独隔离是为了接口标准的需要，而不是为了灵活性。
要实现足够的灵活性，这种分层设计是做不到的
#12
mark
#13
个人认为，分布分层该根据需求而来。DDD强调需求先行，并以通用语言交流为基础。因此，如果楼主只是做个小东西，没必要搞得那么兴师动众。更进一步，如果经过分析，发现在软件的有生之年，其所使用的数据库或者存取方式不会发生变化，那你在这里加入DAL、IDAL岂不是多余。
领域模型对象（实体、值对象和服务）位于领域层，也就是业务层，在作数据展现的时候，可以通过数据传输对象（DTO）进行。数据传输对象是领域对象的数值体现，本意是用来一次打包数据以减少网络程序中服务器与客户机的数据传输来回次数，在DDD中，可以看成是对领域对象的一种封装，即仅向上层公布数值，而不公布业务逻辑。假设将领域对象暴露给其他层，这就变成了其他层可以直接访问业务层中的东西，这并不是一件好事。因此，DTO的引入是有必要的。
对于领域对象的状态持久化，我还是比较看好repository模式的，它把问题简化了：repository负责存储、检索、重建领域对象，这让人很自然地了解到领域对象不仅仅需要处理业务逻辑，而且还会保持着自己的状态，不仅如此，repository如何保存领域对象，将其保存到哪里，领域对象本身甚至是业务逻辑层都不会去关心，这就解耦了业务层和基础结构层。
领域模型对象（实体、值对象和服务）位于领域层，也就是业务层，在作数据展现的时候，可以通过数据传输对象（DTO）进行。数据传输对象是领域对象的数值体现，本意是用来一次打包数据以减少网络程序中服务器与客户机的数据传输来回次数，在DDD中，可以看成是对领域对象的一种封装，即仅向上层公布数值，而不公布业务逻辑。假设将领域对象暴露给其他层，这就变成了其他层可以直接访问业务层中的东西，这并不是一件好事。因此，DTO的引入是有必要的。
对于领域对象的状态持久化，我还是比较看好repository模式的，它把问题简化了：repository负责存储、检索、重建领域对象，这让人很自然地了解到领域对象不仅仅需要处理业务逻辑，而且还会保持着自己的状态，不仅如此，repository如何保存领域对象，将其保存到哪里，领域对象本身甚至是业务逻辑层都不会去关心，这就解耦了业务层和基础结构层。
#14
纠错：
“分布分层” -> “分不分层”
“分布分层” -> “分不分层”
#15
我搞了一段时间，觉得，要是自己独自开发的话，还是，用普通的直接连接数据库好吧！很多人会喷我口水，说我不遵循软件开发的原理。
LS有个朋友说的很对，建个普普通通的茅厕，不需要房屋设计师吧？除非你是建一个豪华别墅里的茅厕再另说吧
LS有个朋友说的很对，建个普普通通的茅厕，不需要房屋设计师吧？除非你是建一个豪华别墅里的茅厕再另说吧
#16
你又怎样知道你修的东西只是一个茅厕呢，说不定你把这个茅厕修好了之后，东西觉得你修得不错，要在你这个茅厕外面做一个宫殿，这个茅厕就成了这个宫殿的卫生间了呢……在大多数情况下，会这样的，不管你信不住，反正我信了……
#1
分层架构确实对效率造成一定的影响，分层次的目的即为了能够体现软件工程里面“高内聚，低耦合”的思想。
优点是：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以用新的实现来替换原有层次的实现；
3、有利于标准化；
4、利于各层次之间的逻辑复用。
缺点是：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、修改代码的时候会导致级联修改。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
优点是：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以用新的实现来替换原有层次的实现；
3、有利于标准化；
4、利于各层次之间的逻辑复用。
缺点是：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、修改代码的时候会导致级联修改。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
#2
ding !
#3
不要为了分层而分层，建一座茅房不需要设计师
#4
Patterns of Enterprise Application Architecture
企业应用架构模式
有时间读读书吧，里面解释得很清楚！
企业应用架构模式
有时间读读书吧，里面解释得很清楚！
#5
避免过度设计，那样做不出东西
#6
实事而论，要看是否有价值
#7
一般 5~6层 可参照 微软的petShop宠物商店
#8
受益
#9
系统小就直接敲代码吧，或者2层足以
#10
学习
#11
你的这个设计不好,特别是
工厂方法IDataFactory类通过反射加载Linq层的程序集，并创建返回Employeer对象，然后业务逻辑层调工厂类的方式。
实际上，业务逻辑一定依赖于业务实体的具体属性，很少会发生实体变更后业务逻辑不发生变化的情况。即便，业务实体需要发生改变，也不会采用仅仅替换数据实体层的方式，要么使用扩展属性，要么使用更复杂的含有元数据的系统。这样的设计毫无必要。通常实体模型单独隔离是为了接口标准的需要，而不是为了灵活性。
要实现足够的灵活性，这种分层设计是做不到的
实际上，业务逻辑一定依赖于业务实体的具体属性，很少会发生实体变更后业务逻辑不发生变化的情况。即便，业务实体需要发生改变，也不会采用仅仅替换数据实体层的方式，要么使用扩展属性，要么使用更复杂的含有元数据的系统。这样的设计毫无必要。通常实体模型单独隔离是为了接口标准的需要，而不是为了灵活性。
要实现足够的灵活性，这种分层设计是做不到的
#12
mark
#13
个人认为，分布分层该根据需求而来。DDD强调需求先行，并以通用语言交流为基础。因此，如果楼主只是做个小东西，没必要搞得那么兴师动众。更进一步，如果经过分析，发现在软件的有生之年，其所使用的数据库或者存取方式不会发生变化，那你在这里加入DAL、IDAL岂不是多余。
领域模型对象（实体、值对象和服务）位于领域层，也就是业务层，在作数据展现的时候，可以通过数据传输对象（DTO）进行。数据传输对象是领域对象的数值体现，本意是用来一次打包数据以减少网络程序中服务器与客户机的数据传输来回次数，在DDD中，可以看成是对领域对象的一种封装，即仅向上层公布数值，而不公布业务逻辑。假设将领域对象暴露给其他层，这就变成了其他层可以直接访问业务层中的东西，这并不是一件好事。因此，DTO的引入是有必要的。
对于领域对象的状态持久化，我还是比较看好repository模式的，它把问题简化了：repository负责存储、检索、重建领域对象，这让人很自然地了解到领域对象不仅仅需要处理业务逻辑，而且还会保持着自己的状态，不仅如此，repository如何保存领域对象，将其保存到哪里，领域对象本身甚至是业务逻辑层都不会去关心，这就解耦了业务层和基础结构层。
领域模型对象（实体、值对象和服务）位于领域层，也就是业务层，在作数据展现的时候，可以通过数据传输对象（DTO）进行。数据传输对象是领域对象的数值体现，本意是用来一次打包数据以减少网络程序中服务器与客户机的数据传输来回次数，在DDD中，可以看成是对领域对象的一种封装，即仅向上层公布数值，而不公布业务逻辑。假设将领域对象暴露给其他层，这就变成了其他层可以直接访问业务层中的东西，这并不是一件好事。因此，DTO的引入是有必要的。
对于领域对象的状态持久化，我还是比较看好repository模式的，它把问题简化了：repository负责存储、检索、重建领域对象，这让人很自然地了解到领域对象不仅仅需要处理业务逻辑，而且还会保持着自己的状态，不仅如此，repository如何保存领域对象，将其保存到哪里，领域对象本身甚至是业务逻辑层都不会去关心，这就解耦了业务层和基础结构层。
#14
纠错：
“分布分层” -> “分不分层”
“分布分层” -> “分不分层”
#15
我搞了一段时间，觉得，要是自己独自开发的话，还是，用普通的直接连接数据库好吧！很多人会喷我口水，说我不遵循软件开发的原理。
LS有个朋友说的很对，建个普普通通的茅厕，不需要房屋设计师吧？除非你是建一个豪华别墅里的茅厕再另说吧
LS有个朋友说的很对，建个普普通通的茅厕，不需要房屋设计师吧？除非你是建一个豪华别墅里的茅厕再另说吧
#16
你又怎样知道你修的东西只是一个茅厕呢，说不定你把这个茅厕修好了之后，东西觉得你修得不错，要在你这个茅厕外面做一个宫殿，这个茅厕就成了这个宫殿的卫生间了呢……在大多数情况下，会这样的，不管你信不住，反正我信了……