49 个解决方案
#1
IDAL是DAL层的类要实现的接口。
DAL层的各类需要完成对数据库的访问，但是不同的数据库需要使用不同的DAL对象，这样对于BLL层来说无法实现数据库无关性。为了实现数据库无关性可以将DAL对象转化为他所实现的接口类型，这样就和具体的数据库访问对象无关了。DAL对象 实现IDAL接口上层程序在使用时不直接DAL对象，而是使用IDAL接口。
DAL层的各类需要完成对数据库的访问，但是不同的数据库需要使用不同的DAL对象，这样对于BLL层来说无法实现数据库无关性。为了实现数据库无关性可以将DAL对象转化为他所实现的接口类型，这样就和具体的数据库访问对象无关了。DAL对象 实现IDAL接口上层程序在使用时不直接DAL对象，而是使用IDAL接口。
#2
任何一种抽象，都是人为的，都是人定的。所以主要是针对不同的人来看“是否合适”，没有什么“怪力”去定是非。
如果一个团队有比较强的系统重构能力，有比较好的软件工程能力，可能它在3个月之后再做系统架构重构也能有勇气去做。这样的团队就不纠结于“洁癖”而是纠结于“快速迭代、持续发布、市场目标”。初学者有一种迭代习惯、刚干了2年的人有一种迭代习惯、5年以上的架构师有另外一种迭代习惯.......
看你的 IDAL 是否必要，主要是看你在那些地方用到了多态，以及这种多态有几毛钱的市场价值。如果有就用。
所谓“代码实现部分都放在了DAL层”这是一种比较令人悲哀的“三层”设计方式。它把业务逻辑都搁到DAL去，而BLL只是一个薄薄的一层多余的摆设。而它既然把业务逻辑搁到DAL中，可以想见，此 BLL 负责架构师在系统的业务需求服务方面的创意一定是非常狭隘、底层化、打不开思路的。
如果一个团队有比较强的系统重构能力，有比较好的软件工程能力，可能它在3个月之后再做系统架构重构也能有勇气去做。这样的团队就不纠结于“洁癖”而是纠结于“快速迭代、持续发布、市场目标”。初学者有一种迭代习惯、刚干了2年的人有一种迭代习惯、5年以上的架构师有另外一种迭代习惯.......
看你的 IDAL 是否必要，主要是看你在那些地方用到了多态，以及这种多态有几毛钱的市场价值。如果有就用。
所谓“代码实现部分都放在了DAL层”这是一种比较令人悲哀的“三层”设计方式。它把业务逻辑都搁到DAL去，而BLL只是一个薄薄的一层多余的摆设。而它既然把业务逻辑搁到DAL中，可以想见，此 BLL 负责架构师在系统的业务需求服务方面的创意一定是非常狭隘、底层化、打不开思路的。
#3
比如说“xxxx代码生成器”，它曾经是个比较流行的框架工具，它给人生成了BLL层、DAL层，以至于5、7年前的许多使用 asp.net 的的小公司在招聘时都用它（使用它）来面试。
然而，它懂什么BLL？它只是从数据库表中产生 BLL、DAL，那么这个软件能懂个屁 BLL 设计啊？它只可能一遍遍地在它的产品文档中蒙蔽那些程序设计师——用数据表的增删改查来伪装BLL，弱化BLL层设计技术。
如果一个软件公司遇到一个糊涂的技术经理，就会真的以为这种就是三层设计了，接下来自己就只要做前端就够了，那样的话所谓“三层”设计就还是成了没有搞懂BLL设计的倾向于两层的设计。这种代码生成器原本只是给你产生一个DAL，它根本不应该冒充自己产生BLL层。
而你则需要设计一个远比DAL复杂得多许多倍的BLL层。为了高效率地设计BLL层，则可以使用通用DAL框架。
然而，它懂什么BLL？它只是从数据库表中产生 BLL、DAL，那么这个软件能懂个屁 BLL 设计啊？它只可能一遍遍地在它的产品文档中蒙蔽那些程序设计师——用数据表的增删改查来伪装BLL，弱化BLL层设计技术。
如果一个软件公司遇到一个糊涂的技术经理，就会真的以为这种就是三层设计了，接下来自己就只要做前端就够了，那样的话所谓“三层”设计就还是成了没有搞懂BLL设计的倾向于两层的设计。这种代码生成器原本只是给你产生一个DAL，它根本不应该冒充自己产生BLL层。
而你则需要设计一个远比DAL复杂得多许多倍的BLL层。为了高效率地设计BLL层，则可以使用通用DAL框架。
#4
只要是不断有新手负责程序设计，这种事情永远都会存在。除非哪天，编程都是各种"alpha够、beta猫“之类的在编程，程序员只负责画蓝图而不负责编程序，那时候可能就不纠结这个DAL、IDAL了。那时候，程序员真正搞懂BLL的设计开发技术了！
事实上，”BLL层去调用IDAL接口层的方法实现，并没有去调用DAL层“这就是调用DAL。一个DAL对象它 就是一个IDAL对象，并不是说有一个IDAL对象保存在DAL对象的”肚子里“。
这只是多态技术。
事实上，”BLL层去调用IDAL接口层的方法实现，并没有去调用DAL层“这就是调用DAL。一个DAL对象它 就是一个IDAL对象，并不是说有一个IDAL对象保存在DAL对象的”肚子里“。
这只是多态技术。
#5
必须要用接口，才能实现层
#6
只是架构上的意义，对新手来说 意义不大，而且还加大代码量。
#7
该回复于2016-06-12 12:34:49被版主删除
#8
分得太多，有利有弊，一般3层就够了
#9
依赖倒置好处，楼主自己查吧
#10
该回复于2016-07-09 13:33:42被管理员删除
#11
三层架构，后台部分核心的设计都在 BLL层。至于说”切换数据库“这个说法对你来说是成立的，也是可以使用各种不同形式的。
当你使用一个成熟的框架时，它自己可能就是可以切换数据库的，但是它同时可能也是通用的。例如许多数据库操作类库，可以通过配置在SQL Server、Oracle、MySQL 之间切换，并不纠结于什么业务对象，也就不纠结于什么 IDAL。
那么看到这个对比，对于 IDAL 就很容易理解了。
一些人首先认为 DAL 就是围绕每一个业务实体类来创建的，甚至傻傻地分不清楚BLL干什么、DAL干什么。然后当听说到”切换数据库“这么高大上的概念时，就很自然地想到了 DAL 需要抽象化为一堆接口或者抽象类.......
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发。实际上这种 DAL、IDAL开发是容易令人“痛苦的、陷入泥潭的”。但是IDAL 相对于这类 DAL 来说，确实“高大上”的概念啊，因为抽象出来接口了嘛！不过重点其实不在于 IDAL，而在于软件三层开发时有没有必要这样来设计 DAL！
当你使用一个成熟的框架时，它自己可能就是可以切换数据库的，但是它同时可能也是通用的。例如许多数据库操作类库，可以通过配置在SQL Server、Oracle、MySQL 之间切换，并不纠结于什么业务对象，也就不纠结于什么 IDAL。
那么看到这个对比，对于 IDAL 就很容易理解了。
一些人首先认为 DAL 就是围绕每一个业务实体类来创建的，甚至傻傻地分不清楚BLL干什么、DAL干什么。然后当听说到”切换数据库“这么高大上的概念时，就很自然地想到了 DAL 需要抽象化为一堆接口或者抽象类.......
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发。实际上这种 DAL、IDAL开发是容易令人“痛苦的、陷入泥潭的”。但是IDAL 相对于这类 DAL 来说，确实“高大上”的概念啊，因为抽象出来接口了嘛！不过重点其实不在于 IDAL，而在于软件三层开发时有没有必要这样来设计 DAL！
#12
了解下设计模式，你就知道为什么要定义接口，再了解下IOC，你就可以利用注入来实例化IDAL的接口
#13
实际上这种 DAL、IDAL开发是容易令人 --> 实际上这种“为了三层而三层”的 DAL、IDAL开发是容易令人
我们把 DAL 中的东西完全忽视，就能看懂一个应用的后台架构有多少创意、有多少技术。而对于那些满脑子只有 DAL 的人就可以不太去关注他了。
而许多外行的管理人员，凭着感觉以为那些整天纠结 DAL 的人似乎很“技术化”，似乎可以长期依赖。这也就是各种入门技术的天然的欺骗性的体现。等你学会忘记 DAL、IDAL，你就能比较好地设计 BLL 层了。
我们把 DAL 中的东西完全忽视，就能看懂一个应用的后台架构有多少创意、有多少技术。而对于那些满脑子只有 DAL 的人就可以不太去关注他了。
而许多外行的管理人员，凭着感觉以为那些整天纠结 DAL 的人似乎很“技术化”，似乎可以长期依赖。这也就是各种入门技术的天然的欺骗性的体现。等你学会忘记 DAL、IDAL，你就能比较好地设计 BLL 层了。
#14
当你们把精力都用在底层，而不想去抽身的时候，当你们还没有把一个老板的钱花光的时候，在任何“层”去玩儿技术就都认为是顺理成章的事情。但是我从 #2 楼开始比较客观地说，首先你选择了“死抠DAL层”的思维方式，这就决定了以后的一堆方向必定是围绕着它而展开。
如果你发现自己需要 DAL 层上抽身出来、真正研发 BLL 层，这时候在应用架构上就能获得很大的提高。而可能在死抠底层“是否需要IDAL”的概念上，没有什么提高。
如果你发现自己需要 DAL 层上抽身出来、真正研发 BLL 层，这时候在应用架构上就能获得很大的提高。而可能在死抠底层“是否需要IDAL”的概念上，没有什么提高。
#15
IDAL层的意义，是屏蔽DAL层具体实现的细节。
BLL调IDAL的情况下：
假如现有的数据库是mysql，调用是：BLL调IDAL，IDAL调MysqlDAL。
要切换到oralce数据库，调用是BLL调IDAL，IDAL调OracleDAL。
这种情况下，根据分层原则， BLL层并不知道IDAL调的是MysqlDAL还是OracleDAL。
BLL调IDAL的情况下：
假如现有的数据库是mysql，调用是：BLL调IDAL，IDAL调MysqlDAL。
要切换到oralce数据库，调用是BLL调IDAL，IDAL调OracleDAL。
这种情况下，根据分层原则， BLL层并不知道IDAL调的是MysqlDAL还是OracleDAL。
#16
该回复于2016-08-31 23:51:48被版主删除
#17
一个是工厂模式 ，一个是简单三层
优点
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
这些缺点在工厂方法模式中得到了一定的克服。
优点
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
这些缺点在工厂方法模式中得到了一定的克服。
#18
学习了，感谢各位前辈的讲解
#19
#20
非常感谢分享
#21
屏蔽DAL层具体实现的细节
#22
感谢耐心回复~
#23
该回复于2016-06-03 10:16:57被管理员删除
#24
www.shop6666.com
很复杂的样子啊！
很复杂的样子啊！
#25
谢谢分享，看看。
#26
该回复于2016-06-12 12:34:50被版主删除
#27
该回复于2016-07-09 13:33:42被管理员删除
#28
#29
该回复于2017-10-31 19:56:07被版主删除
#30
有了接口，那么依赖接口就可以了。不需要等所有代码都实现，就可以去写依赖于这个部分的代码。不过这种也是非常古老并且过时的设计了。现在比较流行的是微服务架构，对于微服务来说，接口是对外的服务契约。
#31
以前了解过的，时间长了又忘了 ，让我温故了一下 感谢各位
#32
该回复于2016-06-12 12:34:50被版主删除
#33
11111111111111111111111
#34
人家只是问下为什么要定义这个接口层，不知道你们干嘛引申出那么多想法？
简单来说就是为了当更换不同类型的数据库时只需要生成对应的数据操作层的代码，并且修改下webconfig的配置就行了，不需要修改其他层面的代码。
就这样！
简单来说就是为了当更换不同类型的数据库时只需要生成对应的数据操作层的代码，并且修改下webconfig的配置就行了，不需要修改其他层面的代码。
就这样！
#35
就是为了解耦。调用接口方，不关心idal的具体实现。
idal哪怕是还了数据库，修改了数据类型，这些都和你没关系。
只要他 最后提供了你接口，就可以了。这就是分层和解耦。
实际项目中的运用，可能是这样的。
你负责前台和一些数据获取，另一个程序员X 负责dal层开发。
为了并行开发，他只需要先给你idal层的接口，就算他还没有实现部分功能。
但是你这边已经可以通过idal层来进行代码编写了。
而不是等他dal层写完了，你才能调用dal的方法。
idal哪怕是还了数据库，修改了数据类型，这些都和你没关系。
只要他 最后提供了你接口，就可以了。这就是分层和解耦。
实际项目中的运用，可能是这样的。
你负责前台和一些数据获取，另一个程序员X 负责dal层开发。
为了并行开发，他只需要先给你idal层的接口，就算他还没有实现部分功能。
但是你这边已经可以通过idal层来进行代码编写了。
而不是等他dal层写完了，你才能调用dal的方法。
#36
这样DAL的调用层，只依赖接口，实际数据库操作的对象可使用工厂模式生成（使用C#的反射机制)。
这样，可以实现对多种数据库的支持。
这样，可以实现对多种数据库的支持。
#37
使用接口可以减低耦合啊，比如我BLL层的业务要变动了，但是返回的数据模型和要用到的参数还是不变的话，那么我们只需要让新业务实现同样的接口就可以了，UI层不需要怎么变动，如果你用IOC的话，只需要改变一下配置文件的配置就可以了，这样BLL层的变动对系统的影响减到最低
#38
Learning learning 学习啦 learning
#39
厉害学学，讲的太好了
#40
占楼学习知识
#41
i can't agree more 我不能同意更多
#42
就是面向接口编程，降低模块间的耦合度，依赖抽象而不依赖具体的实现，修改维护起来方便一点。
个人理解，但是目前也没怎么体会到好处，没做过大点的项目。
等正真去用了才能体会到把，现在也只是理解。
个人理解，但是目前也没怎么体会到好处，没做过大点的项目。
等正真去用了才能体会到把，现在也只是理解。
#43
#44
p哥的话，总是让人叹服，直击问题的真相，为我们指引了未来的方向
就看这句话，大家是不是感觉自己曾经写的DAL层，都是太笨重了？
就看这句话，大家是不是感觉自己曾经写的DAL层，都是太笨重了？
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发
#45
评论很精彩啊，现在数据层应该是各种orm框架吧
#46
看不懂，来学习的
#47
看下IOC，设计模式
#48
大哥，你提供的链接404 的！
#49
回复时间正好一年,多了几天
#1
IDAL是DAL层的类要实现的接口。
DAL层的各类需要完成对数据库的访问，但是不同的数据库需要使用不同的DAL对象，这样对于BLL层来说无法实现数据库无关性。为了实现数据库无关性可以将DAL对象转化为他所实现的接口类型，这样就和具体的数据库访问对象无关了。DAL对象 实现IDAL接口上层程序在使用时不直接DAL对象，而是使用IDAL接口。
DAL层的各类需要完成对数据库的访问，但是不同的数据库需要使用不同的DAL对象，这样对于BLL层来说无法实现数据库无关性。为了实现数据库无关性可以将DAL对象转化为他所实现的接口类型，这样就和具体的数据库访问对象无关了。DAL对象 实现IDAL接口上层程序在使用时不直接DAL对象，而是使用IDAL接口。
#2
任何一种抽象，都是人为的，都是人定的。所以主要是针对不同的人来看“是否合适”，没有什么“怪力”去定是非。
如果一个团队有比较强的系统重构能力，有比较好的软件工程能力，可能它在3个月之后再做系统架构重构也能有勇气去做。这样的团队就不纠结于“洁癖”而是纠结于“快速迭代、持续发布、市场目标”。初学者有一种迭代习惯、刚干了2年的人有一种迭代习惯、5年以上的架构师有另外一种迭代习惯.......
看你的 IDAL 是否必要，主要是看你在那些地方用到了多态，以及这种多态有几毛钱的市场价值。如果有就用。
所谓“代码实现部分都放在了DAL层”这是一种比较令人悲哀的“三层”设计方式。它把业务逻辑都搁到DAL去，而BLL只是一个薄薄的一层多余的摆设。而它既然把业务逻辑搁到DAL中，可以想见，此 BLL 负责架构师在系统的业务需求服务方面的创意一定是非常狭隘、底层化、打不开思路的。
如果一个团队有比较强的系统重构能力，有比较好的软件工程能力，可能它在3个月之后再做系统架构重构也能有勇气去做。这样的团队就不纠结于“洁癖”而是纠结于“快速迭代、持续发布、市场目标”。初学者有一种迭代习惯、刚干了2年的人有一种迭代习惯、5年以上的架构师有另外一种迭代习惯.......
看你的 IDAL 是否必要，主要是看你在那些地方用到了多态，以及这种多态有几毛钱的市场价值。如果有就用。
所谓“代码实现部分都放在了DAL层”这是一种比较令人悲哀的“三层”设计方式。它把业务逻辑都搁到DAL去，而BLL只是一个薄薄的一层多余的摆设。而它既然把业务逻辑搁到DAL中，可以想见，此 BLL 负责架构师在系统的业务需求服务方面的创意一定是非常狭隘、底层化、打不开思路的。
#3
比如说“xxxx代码生成器”，它曾经是个比较流行的框架工具，它给人生成了BLL层、DAL层，以至于5、7年前的许多使用 asp.net 的的小公司在招聘时都用它（使用它）来面试。
然而，它懂什么BLL？它只是从数据库表中产生 BLL、DAL，那么这个软件能懂个屁 BLL 设计啊？它只可能一遍遍地在它的产品文档中蒙蔽那些程序设计师——用数据表的增删改查来伪装BLL，弱化BLL层设计技术。
如果一个软件公司遇到一个糊涂的技术经理，就会真的以为这种就是三层设计了，接下来自己就只要做前端就够了，那样的话所谓“三层”设计就还是成了没有搞懂BLL设计的倾向于两层的设计。这种代码生成器原本只是给你产生一个DAL，它根本不应该冒充自己产生BLL层。
而你则需要设计一个远比DAL复杂得多许多倍的BLL层。为了高效率地设计BLL层，则可以使用通用DAL框架。
然而，它懂什么BLL？它只是从数据库表中产生 BLL、DAL，那么这个软件能懂个屁 BLL 设计啊？它只可能一遍遍地在它的产品文档中蒙蔽那些程序设计师——用数据表的增删改查来伪装BLL，弱化BLL层设计技术。
如果一个软件公司遇到一个糊涂的技术经理，就会真的以为这种就是三层设计了，接下来自己就只要做前端就够了，那样的话所谓“三层”设计就还是成了没有搞懂BLL设计的倾向于两层的设计。这种代码生成器原本只是给你产生一个DAL，它根本不应该冒充自己产生BLL层。
而你则需要设计一个远比DAL复杂得多许多倍的BLL层。为了高效率地设计BLL层，则可以使用通用DAL框架。
#4
只要是不断有新手负责程序设计，这种事情永远都会存在。除非哪天，编程都是各种"alpha够、beta猫“之类的在编程，程序员只负责画蓝图而不负责编程序，那时候可能就不纠结这个DAL、IDAL了。那时候，程序员真正搞懂BLL的设计开发技术了！
事实上，”BLL层去调用IDAL接口层的方法实现，并没有去调用DAL层“这就是调用DAL。一个DAL对象它 就是一个IDAL对象，并不是说有一个IDAL对象保存在DAL对象的”肚子里“。
这只是多态技术。
事实上，”BLL层去调用IDAL接口层的方法实现，并没有去调用DAL层“这就是调用DAL。一个DAL对象它 就是一个IDAL对象，并不是说有一个IDAL对象保存在DAL对象的”肚子里“。
这只是多态技术。
#5
必须要用接口，才能实现层
#6
只是架构上的意义，对新手来说 意义不大，而且还加大代码量。
#7
该回复于2016-06-12 12:34:49被版主删除
#8
分得太多，有利有弊，一般3层就够了
#9
依赖倒置好处，楼主自己查吧
#10
该回复于2016-07-09 13:33:42被管理员删除
#11
三层架构，后台部分核心的设计都在 BLL层。至于说”切换数据库“这个说法对你来说是成立的，也是可以使用各种不同形式的。
当你使用一个成熟的框架时，它自己可能就是可以切换数据库的，但是它同时可能也是通用的。例如许多数据库操作类库，可以通过配置在SQL Server、Oracle、MySQL 之间切换，并不纠结于什么业务对象，也就不纠结于什么 IDAL。
那么看到这个对比，对于 IDAL 就很容易理解了。
一些人首先认为 DAL 就是围绕每一个业务实体类来创建的，甚至傻傻地分不清楚BLL干什么、DAL干什么。然后当听说到”切换数据库“这么高大上的概念时，就很自然地想到了 DAL 需要抽象化为一堆接口或者抽象类.......
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发。实际上这种 DAL、IDAL开发是容易令人“痛苦的、陷入泥潭的”。但是IDAL 相对于这类 DAL 来说，确实“高大上”的概念啊，因为抽象出来接口了嘛！不过重点其实不在于 IDAL，而在于软件三层开发时有没有必要这样来设计 DAL！
当你使用一个成熟的框架时，它自己可能就是可以切换数据库的，但是它同时可能也是通用的。例如许多数据库操作类库，可以通过配置在SQL Server、Oracle、MySQL 之间切换，并不纠结于什么业务对象，也就不纠结于什么 IDAL。
那么看到这个对比，对于 IDAL 就很容易理解了。
一些人首先认为 DAL 就是围绕每一个业务实体类来创建的，甚至傻傻地分不清楚BLL干什么、DAL干什么。然后当听说到”切换数据库“这么高大上的概念时，就很自然地想到了 DAL 需要抽象化为一堆接口或者抽象类.......
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发。实际上这种 DAL、IDAL开发是容易令人“痛苦的、陷入泥潭的”。但是IDAL 相对于这类 DAL 来说，确实“高大上”的概念啊，因为抽象出来接口了嘛！不过重点其实不在于 IDAL，而在于软件三层开发时有没有必要这样来设计 DAL！
#12
了解下设计模式，你就知道为什么要定义接口，再了解下IOC，你就可以利用注入来实例化IDAL的接口
#13
实际上这种 DAL、IDAL开发是容易令人 --> 实际上这种“为了三层而三层”的 DAL、IDAL开发是容易令人
我们把 DAL 中的东西完全忽视，就能看懂一个应用的后台架构有多少创意、有多少技术。而对于那些满脑子只有 DAL 的人就可以不太去关注他了。
而许多外行的管理人员，凭着感觉以为那些整天纠结 DAL 的人似乎很“技术化”，似乎可以长期依赖。这也就是各种入门技术的天然的欺骗性的体现。等你学会忘记 DAL、IDAL，你就能比较好地设计 BLL 层了。
我们把 DAL 中的东西完全忽视，就能看懂一个应用的后台架构有多少创意、有多少技术。而对于那些满脑子只有 DAL 的人就可以不太去关注他了。
而许多外行的管理人员，凭着感觉以为那些整天纠结 DAL 的人似乎很“技术化”，似乎可以长期依赖。这也就是各种入门技术的天然的欺骗性的体现。等你学会忘记 DAL、IDAL，你就能比较好地设计 BLL 层了。
#14
当你们把精力都用在底层，而不想去抽身的时候，当你们还没有把一个老板的钱花光的时候，在任何“层”去玩儿技术就都认为是顺理成章的事情。但是我从 #2 楼开始比较客观地说，首先你选择了“死抠DAL层”的思维方式，这就决定了以后的一堆方向必定是围绕着它而展开。
如果你发现自己需要 DAL 层上抽身出来、真正研发 BLL 层，这时候在应用架构上就能获得很大的提高。而可能在死抠底层“是否需要IDAL”的概念上，没有什么提高。
如果你发现自己需要 DAL 层上抽身出来、真正研发 BLL 层，这时候在应用架构上就能获得很大的提高。而可能在死抠底层“是否需要IDAL”的概念上，没有什么提高。
#15
IDAL层的意义，是屏蔽DAL层具体实现的细节。
BLL调IDAL的情况下：
假如现有的数据库是mysql，调用是：BLL调IDAL，IDAL调MysqlDAL。
要切换到oralce数据库，调用是BLL调IDAL，IDAL调OracleDAL。
这种情况下，根据分层原则， BLL层并不知道IDAL调的是MysqlDAL还是OracleDAL。
BLL调IDAL的情况下：
假如现有的数据库是mysql，调用是：BLL调IDAL，IDAL调MysqlDAL。
要切换到oralce数据库，调用是BLL调IDAL，IDAL调OracleDAL。
这种情况下，根据分层原则， BLL层并不知道IDAL调的是MysqlDAL还是OracleDAL。
#16
该回复于2016-08-31 23:51:48被版主删除
#17
一个是工厂模式 ，一个是简单三层
优点
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
这些缺点在工厂方法模式中得到了一定的克服。
优点
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；
这些缺点在工厂方法模式中得到了一定的克服。
#18
学习了，感谢各位前辈的讲解
#19
#20
非常感谢分享
#21
屏蔽DAL层具体实现的细节
#22
感谢耐心回复~
#23
该回复于2016-06-03 10:16:57被管理员删除
#24
www.shop6666.com
很复杂的样子啊！
很复杂的样子啊！
#25
谢谢分享，看看。
#26
该回复于2016-06-12 12:34:50被版主删除
#27
该回复于2016-07-09 13:33:42被管理员删除
#28
#29
该回复于2017-10-31 19:56:07被版主删除
#30
有了接口，那么依赖接口就可以了。不需要等所有代码都实现，就可以去写依赖于这个部分的代码。不过这种也是非常古老并且过时的设计了。现在比较流行的是微服务架构，对于微服务来说，接口是对外的服务契约。
#31
以前了解过的，时间长了又忘了 ，让我温故了一下 感谢各位
#32
该回复于2016-06-12 12:34:50被版主删除
#33
11111111111111111111111
#34
人家只是问下为什么要定义这个接口层，不知道你们干嘛引申出那么多想法？
简单来说就是为了当更换不同类型的数据库时只需要生成对应的数据操作层的代码，并且修改下webconfig的配置就行了，不需要修改其他层面的代码。
就这样！
简单来说就是为了当更换不同类型的数据库时只需要生成对应的数据操作层的代码，并且修改下webconfig的配置就行了，不需要修改其他层面的代码。
就这样！
#35
就是为了解耦。调用接口方，不关心idal的具体实现。
idal哪怕是还了数据库，修改了数据类型，这些都和你没关系。
只要他 最后提供了你接口，就可以了。这就是分层和解耦。
实际项目中的运用，可能是这样的。
你负责前台和一些数据获取，另一个程序员X 负责dal层开发。
为了并行开发，他只需要先给你idal层的接口，就算他还没有实现部分功能。
但是你这边已经可以通过idal层来进行代码编写了。
而不是等他dal层写完了，你才能调用dal的方法。
idal哪怕是还了数据库，修改了数据类型，这些都和你没关系。
只要他 最后提供了你接口，就可以了。这就是分层和解耦。
实际项目中的运用，可能是这样的。
你负责前台和一些数据获取，另一个程序员X 负责dal层开发。
为了并行开发，他只需要先给你idal层的接口，就算他还没有实现部分功能。
但是你这边已经可以通过idal层来进行代码编写了。
而不是等他dal层写完了，你才能调用dal的方法。
#36
这样DAL的调用层，只依赖接口，实际数据库操作的对象可使用工厂模式生成（使用C#的反射机制)。
这样，可以实现对多种数据库的支持。
这样，可以实现对多种数据库的支持。
#37
使用接口可以减低耦合啊，比如我BLL层的业务要变动了，但是返回的数据模型和要用到的参数还是不变的话，那么我们只需要让新业务实现同样的接口就可以了，UI层不需要怎么变动，如果你用IOC的话，只需要改变一下配置文件的配置就可以了，这样BLL层的变动对系统的影响减到最低
#38
Learning learning 学习啦 learning
#39
厉害学学，讲的太好了
#40
占楼学习知识
#41
i can't agree more 我不能同意更多
#42
就是面向接口编程，降低模块间的耦合度，依赖抽象而不依赖具体的实现，修改维护起来方便一点。
个人理解，但是目前也没怎么体会到好处，没做过大点的项目。
等正真去用了才能体会到把，现在也只是理解。
个人理解，但是目前也没怎么体会到好处，没做过大点的项目。
等正真去用了才能体会到把，现在也只是理解。
#43
#44
p哥的话，总是让人叹服，直击问题的真相，为我们指引了未来的方向
就看这句话，大家是不是感觉自己曾经写的DAL层，都是太笨重了？
就看这句话，大家是不是感觉自己曾经写的DAL层，都是太笨重了？
实际上如果一个开发 ORM 的人肯定不这样设计！因为数据库操作层框架是在开发”任何“应用之前就开发和发布出来的，是通用的，而不是根据每一个应用都要重新做一套 DAL 开发
#45
评论很精彩啊，现在数据层应该是各种orm框架吧
#46
看不懂，来学习的
#47
看下IOC，设计模式
#48
大哥，你提供的链接404 的！
#49
回复时间正好一年,多了几天