關於三層架構中的IBLL

public interface IUser
{
void Insert(User user);
void Update(User user);
}
和数据交互DAL，交互部分IDAL，对DAL扩展不同的接口
与ORM主要是通用性
public class TEST: IDisposable
{
public void Add(object obj){}
public void Update(object obj){}
}

没见过这样做的
或许是有两个子类继承自同一个类，IBLL可以在两个model之间切换？？

這個地方我可以理解。不明白的是IBLL曾
這個例子説明了什麽問題呢，能不能詳細指導一下。

我想應該不會。
类比对IDAL 的理解。IBLL因该是对BLL的抽象，一个项目业务逻辑应该是很具体吧，这种抽象又有什么意义呢.难道要做出通用的项目！！！

比如我做过的一个项目，用户分个人用户和企业用户，分别存在两张表里面（确实很杯具，接手的时候觉得改起来工作量大，不想改了），就可以把共同的部分比如用户名、密码、注册邮件、密码保护等抽象成一个“用户”类，不同的用户类型再继承“用户”类，DAL层有对应两个类的不同操作方法不知道举这个例子合不合适，，一开始我把用户写成了全不相干的两个类，后来杯具了，项目要求所有用户用同一套会员卡，

不问，不追，不想一切惟心IBIL只是写他人心里在想着：依赖倒置，单一职责这类事情所以IBIL并不是一开始就有的，他是重构出来的，重构的目的是：“对外提供单一的职责”，“抽象出不变的，外部依靠这些抽象，而不是具象”IBIL产生的途径有两种
1。重构出来的泛化抽象----这类是后期重构出来的
2。领域模型或业务用例的动作操作部分------这类有可能是前期设计出来的，但通常情况下任然是后期重构滴，因为领域或用例分析大多数时候是实体和动作混搭的，重构出IBal只是为他把混搭的模型条理化，对外只提供单一的功能

这个例子好像没有回答我的问题。不过我觉得你可以把个人用户和企业用户的操作定义一个接口IUser然后再DAL中分别实现。

我不是要说怎么继承，继承类和继承接口不重要。
我说的是BLL中怎么切换，难道要写两遍？？
也不一定要多出IBLL这个层来，而是说既然他写出了这个层，应该起差不多类似的作用

现实的意义就在于：软件开发不是民工盖楼，而更像古代建筑师的记忆。古代建筑师没有什么建筑CAD，它也不可能用花费、耗时巨大的方法去设计建筑，唯一的办法就是制作模型来分析建筑。开发软件时，每一步骤、每一个10分钟，你都要按F5来让程序跑起来，然后从编译或者运行的异常中靠解决bug来驱动出你的设计思路（因此没有bug就没有程序的进步）。这个过程不可能花费、耗时巨大，因此你往往不可能用真实的数据库、底层硬件、高层操作，而是使用实现了同一接口的各种“假的”测试驱动程序。比如说，你把微软的数据绑定控件从工具箱拖入设计窗口，立刻，这个控件就显示出一堆假数据、假字段结构。之后你可以定义字段，然后控件立刻显示新的假数据。让你可以尽可能直观的设计界面。而不是真的去连接（可能经常崩溃的）数据库。因此面向接口编程，并且使用替代模型来进行阶段性开发，对于外行来说只会以为这种方式比较费事，对于内行来说则可以做到别人根本无法做到的敏捷开发。

单看这个就没有什么意义，因为它太空洞了。可能看它的后继类型再返过来看它才有点意义。实际上当确立一个接口，设计师脑子里就有一幅蓝图，它知道哪段代码、哪一个人认领的任务、哪一个人的能力范围在实现着它，同时它也知道不同的接口实现之间如何迅速而轻巧地拼凑起来，同时它开始构思长期保持接口的各种后继实现组件的稳定性的问题。而这个时候代码可能根本还没有展开开发工作，只是对今后两周的系统组件进行概要设计阶段。至于说三层中常见的接口，是这种软件工程风格的体现.真正的设计师会自己设计上百个此类东西用在系统中，而绝非copy来别人的1、2个接口就当作宝典了。

的确如此，了解的人是不怎么去提3层，N层，BIL，Dal这类东西滴。就像我前面说的一切惟心，笔，颜料，纸都给你了，想怎么画就怎么画，不必去强调俺是野兽派还是印象派

我傾向于接受你的第二點。
不太理解你爲什麽要說 "所以IBIL并不是一开始就有的，他是重构出来的....."
我觉得接口都是很穩定的東西，對接口的修改會導致牽一發而动全身。
而重构出这一层，是不是意味着对整个项目的颠覆？

个人觉得提供这样一个接口是为了系统的可复用，可以抽取一些逻辑处理类的公共部分，例如一些数据库访问类可以提供IBLL接口，那么BLL可以去继承这些接口实现其方法。

IBLL是古代建筑师手中的模型吗？

呵呵，与其说他是模型不如说他是脚手架
既然是脚手架，自然是为了方便，如果他挡道了，或者以不合时宜了自然要拆除，要重构实际上你没明白现代软件开发的一般状态，现代软件开发并不是像传统开发那样，直接上手就是细节。现代软件开发讲究抽象，就像ls老p说滴：“模型，任务，打桩测试，重构”才是现代软件开发的常态。还是来比方：现代软件开发更像是传统的雕塑家，没人一上就开始雕鼻子眉毛滴。通常的雕塑家在选型完毕后，上来实际都是做一些粗糙的工作，整体的比例，大致的形状------要是一上来就玩细节，麻烦大了！鼻子眉毛是挺精致，可惜男人脑袋配了个女人身子

大家的理论太高深了，要么就是跑题了。
能不能来点实惠的？
有谁的项目中用到这个。是怎么用的
要不我出个题。假设公司要写个请假的程序 leave 公司有3个办事处 A,B,C
3个办事处假期申请流程，取消，审批，参数设定都不一样。但总的来说都有这些东西
你会怎么设计这个业务逻辑接口，才能保证将来添加一个办事处对既有程序不回造成影响？

举个简单的例子。
经理突然说要把数据库换成oracle或mysql。
你只要有IDAL层，继承下接口，重新写sql语句。就可以了当然以后linq可以支持多种数据库后，这IDAL应该就不需要了。

根据题意定义了一个粗糙的接口，你也可以将object再接口化，只是一个参考样例
interface IBSCP
        {
            object CQP { get; }
            object QXP { get; }
            object SPP { get; }
        }
        interface IBSC<paramterType> where paramterType : IBSCP
        {
            valueType P;
            bool CQ();
            void QX();
            bool SP();
        }

怎么还在纠结啊？呵呵
你说的这个项目有点问题，并不合适。。
3“个”办事处，既然是具体的个体那就是实例了，实际上应该处理的是类，3“种”部门就合适
假期.申请() .取消() .审批()这些方法我把它看成是三种部门的共性，在BLL中是一样的，你说的具体实现不一样可以交给下一层去解决（如果连参数、返回类型都不一样，那就不是相同的方法了）。
除此之外三种部门应该有不一样的地方，比如A部门有属性“销售业绩”，B部门有方法.备案（），其它部门没有。这些我们不管，我们只抽出它们的共性：假期的申请、取消、审批。。

为什么说它是重构出来的？
一开始我们可能会这样做：假期的申请我们会在BLL中定义部门A的假期申请方法、部门B的假期申请方法这样做肯定不行，部门少了还好办，如果有成百上千种部门都定义一遍。。怎么办？推倒重来我们可以只定义一次部门的假期申请方法，然后可以判断如果是部门A，就可以调用DAL中部门A的处理方法，如果是部门B、C，都调用DAL中对应的方法。。但是这样又有问题了，我们不可能在所有的方法中把所有的部门都判断一遍吧？？怎么办？推倒重来我们可以不在BLL中做这种判断类型（部门）的工作，或者说把这个判断的工作交给实例化的过程，你实例化了哪个部门，它自然就去调用DAL中对应的方法了。比如说，上海的销售处的请假申请，我们可以先new一个销售处的实例，然后调用部门（注意，不是销售处）的假期申请方法就行了；如果是北京的售后服务部的请假审批，我们可以先new一个售后服务部的实例，然后调用部门的请假审批方法就OK了IBLL应该就是处理这些工作的，不是说它必须有，就像IDAL一样，我们完全可以在BLL中明确地调用dal，但是这样就不灵活了，如果我们从某种存储介质（比如access数据库）切换到另一种（比如xml文件），总不可能去改BLL中的代码吧？加个IDAL就解决了。同样，IBLL就可以让我们不用管到底是哪种部门。这样，如果我们要添加一种部门D，就好办了，只要在Model中添加部门D这个类，在DAL中添加相应的处理方法就OK了

呵呵，许多程序员满脑子就只有数据库表，他把用户需求字斟句酌地匹配到数据库表以及外键定义上，离开了数据库表就“活不了”（无法表述软件需求）。结果久而久之，只是习惯于耗费巨大的精力纠结数据库表之后，围绕每一个数据库表去人为地拼凑什么“增删改查”操作界面，最后再用这种东西作为文档去分工、甚至拿给最终用户看。结果我们既看到无数千篇一律的、OA类的软件界面。看看许多真正流行的软件你就会发现，好的软件往往是从交互出发来定义的，设计者做一件事的稳定性、能力表现在对交互操作的诠释。也就是说，软件的表现层是最重要的，通过对这个层次的需求接口的分析和设计，达到了一定的信心指数，我们就开始动手开发软件。而不是纠缠于底层的细节（反而不去重视外在表现层的框架合同）来盲目开发。在有限的时间内，抓住高层次的东西（比如各种客户端在组件适配、通讯网关搭建方面的不同点需要抽象统一），而底层的靠近DAL层次东西则是可以不太纠结、保持灵活性的。结果我看到的“重构”这个词首要地是要区分两种不同的说辞的，两种说法根本不能混同。一种是只是纠结于数据库表，于是重构被说成是不断重新做增删改查的界面；另一种是把底层的东西看作不紧急的，如果用文件可以实现就没有必要立刻使用数据库实现，把时间用在驱动出高层次的组件的协调开发。站在第一种角度，它就除了数据库表找不到多少设计架构了，它的开发时从底层向上自己去拼凑着接近人家的高层次要求。而站在第二种角度，正相反，它可以一开始就重视架构接口的设计问题，它的开发时把握高层次设计接口然后监督、激励和协调各种代码民工实现接口。什么是稍微复杂一点的软件的设计要点？不是底层的数据库，而是软件的交互表现。开发一个软件应该从表现层出发来把握，而底层的东西我们可以先用一个个假的模型实现来架空它，先集中精力完成高层次接口实现。

嗯，不管是从哪一个角度，实际上设计的目的是为了尽早自动化，而不是停留在纸上。如果停留在纸上，就是垃圾，我会寝食难安。我不是一个空话连篇的人，我的编程速度是很快很快地，编程的同时我心里可以装着好几个同事每半天正在做的程序的特性随时给它们重温以前讨论细节（他们未必记得）。我自己大概每隔几分钟就会按F5键。因为bug是驱动我们进行下一步编程的主要动力，所以我们不能在那里闷头“开发”一个小时才去F5。编程者如果习惯小步快跑，要比年轻轻地就习惯老态龙钟地挪动着编程要好很多。但是这前提是什么？是彻底改变一种思想，是要放下一种理论堆砌的包袱，一切以测试说了算。但是测试什么？先写下测试然后让程序通过测试，而不会承担更大的压力（更不应该加班）。搞管理和搞纯技术的区别是什么？至少我不是那种让人鄙夷的管理者，我希望也不要把程序PM理解为国内的那些高高在上的管理者。其实我谈的都是技术，我的程序员在动手编程之前都已经跟我一样熟悉了要做的程序的特性，我的职责就是建立信心然后才编程，而不是硬逼着程序员去替我设计程序的特性然后人家实现了之后再反悔而对人家的设计说三道四。所以我并不希望把把握项目跟“纯技术”对立起来。要知道“纯技术”是有害的，真正好的技术表现同时也是非常务实的。

嗯，上边不小心写了三楼，而其中没有具体表明lz的问题。其实围绕的中心点还是不变的，只不过我变换着不同角度。具体来说，lz对DAL建模的倾向可以接受，但是对BLL建模的倾向则不太理解，这当然是一种常见的通病。我们从小学东西往往被“填鸭”的，期末考试卷子上的题目其实暗示了我们可以套用某本刚学过的教材的某章某节上的例题，我们没有学过反观自己的思维习惯。以至于10几年之后研究能力没有养成就被投放到社会上工作了。于是很自然地，在工作了一段时间（5年以内）还是不理解如何设计软件才能很好地适合需求。基本上，软件工程的知识都不是绝对的。我以前接触人工智能技术时记得很清楚的一个公理是这样的：把一只猴子放到国家图书馆里边足够长时间，它就能把所有文献我们输入到电脑里边。也就是说，如果我们找50个程序员，20个测试人员，没日没夜地加班，工作2年之后也能拼凑出一个看似不错的软件（但是千万别更改需求、千万别更换管理者）。因此软件工程知识是相对的，你熟悉了一种很务实的设计和控制风格，就离不开它了，而别人则可能根本闻所未闻。而我要提醒lz的就是，相对来说，DAL远远不如BLL更要紧。如果你发现自己只是对DAL过度建模很痴迷，可以考虑先放下这种东西一段时间。

就是连同工厂、接口、控制层、全部在一起的MVC模式。普通的三层结构：UI / BLL / DAL ，数据实体使用 Model 封装。这种“三层结构”之间是顺序的调用关系，UI 调用 BLL ，BLL 将操作组织并安排 DAL 层，DAL 层操作数据库，每层之间的关系都很紧密，所以协同开发时互相的依赖性较强，项目结构耦合度大。基于高内聚低耦合的原则，层和层之间的调用考虑引入接口 IDAL 进行规范和分割。
http://www.wei2008.com/News/News/5496.html建议LZ看看。

应该是来封装实例化不同的Bll对象。看看设计模式。

sp1234老大在csdn的权威是毋庸置疑的。像以前我发的很多帖子一样，都有你的回复。像以前一样还是看不懂你的回复。还是那句话：纸上得来终觉浅，绝知此事要躬行。能否把您写过的某个项目连同文档发一份给小弟。让我好好按F11拜读一下呢。

你妈妈喜欢（用尺子）打你；
你爸爸喜欢（用棍子）打你；
你老婆喜欢（用美腿）打你。“家人打你”这个逻辑，根据执行家人的不同角色，实现也不一样。（尺子、棍子、美腿）而业务场景：
当家人发现你有外遇了，你将被家人打。只要调用“家人打你”这个逻辑
IBLL与BLL内的IINT有什么不同？想清楚你就清楚了

调试易

關於三層架構中的IBLL

解决方案 »