紧急求救：关于对应表示层的业务外观（见MartinFlower分析模式）的问题？
比如有一UI显示组件BusinessUI，应用逻辑层有一对应业务外观BusinessFacade；在将具体的业务逻辑委派给领域层的对象。
在显示UI显示组件BusinessUI同时要求在打开该UI显示组件弹出查询条件的对话框QueryDlg，也设计了一对应的业务外观DlgFacade；
对话框组件要传入查询参数给UI显示组件BusinessUI,实际上在处理时我将对话框的查询参数传入对应的业务外观DlgFacade进行业务逻辑的处理，目前真正需要的查询参数的是UI显示组件BusinessUI和对应业务外观BusinessFacade（具体我觉得应该是BusinessFacade关联了DlgFacade，这有一个问题，BusinessUI应该不会需要关联DlgFacade？）。目前设计BusinessUI关联的QueryDlg（考虑在BusinessUI显示时QueryDlg同时出现在上方，所以有UI组件的关联），请问这合理吗？不合理的地方在哪里？
问题点数：0、回复次数：10Top
1 楼shipp（嘎子）回复于 2005-06-02 23:06:22 得分 0
请高手和阎大哥jeffyan77和指点,谢谢：）Top
2 楼shipp（嘎子）回复于 2005-06-02 23:23:52 得分 0
谈到领域层设计，我感觉从用户目标级用例中抽取对系统有意义的名词作为领域类时，再到分析类－》设计类的过程，我感觉基本上出来的都是具体类。在领域层提取类层次的机会很少。
对于双向直接关联的类也很多，比如task下会有多个taskitem
Class Task
{
...
List taskItem;
}
Class TaskItem
{
...
Task task;
}
具体在业务中理解，在通讯中，可以想后台放送一个Task，放回多个TaskItem，TaskItem中又比较具有Task的部分属性，是否这只能是作为双向强关联？Top
3 楼shipp（嘎子）回复于 2005-06-02 23:25:39 得分 0
具体在业务中理解，在通讯程序中，Client端向Server端放送一个Task，返回多个TaskItem，而TaskItem中又必须具有Task的部分属性，是否这只能是作为双向强关联？
Top
4 楼taglib（不懂就是不懂，别不懂装懂）回复于 2005-06-03 03:42:01 得分 0
看看名字，为什么要分BusinessUI/BusinessFacade，QueryDlg/DlgFacade？ 难道是按GUI分类的？？？分类是否合理？
====“具体我觉得应该是BusinessFacade关联了DlgFacade，这有一个问题，BusinessUI应
该不会需要关联DlgFacade？）。”
不应该是关联不关联的问题，而是BusinessFacade与DlgFacade里的东西组织得是否
合理的问题
====“考虑在BusinessUI显示时QueryDlg同时出现在上方，所以有UI组件的关联”
QueryDlg与BusinessUI是独立的么？还是在BusinessUI里需要显示QueryDlg?
BusinessFacade bf;
//.
QueryDlg dlg = new QueryDlg();
dlg.PropertyA = bf.A; //显示
dlg.PropertyB = bf.B; //显示
dlg.DoModal();
bf.C = dlg.PropertyC; //输出
bf.D = dlg.PropertyD; //输出
bf.Validate();Top
5 楼taglib（不懂就是不懂，别不懂装懂）回复于 2005-06-03 03:45:07 得分 0
===="谈到领域层设计，我感觉从用户目标级用例中抽取对系统有意义的名词作为领域类时"
光从用例里抽取领域知识是很有问题的，你需要从业务所在领域出发Top
6 楼shipp（嘎子）回复于 2005-06-03 21:25:54 得分 0
看看名字，为什么要分BusinessUI/BusinessFacade，QueryDlg/DlgFacade？ 难道是按GUI分类的？？？分类是否合理？
不是按GUI分类，只是想将表示层同业务逻辑层解耦合，UI组件将需要进行业务处理的数据传递到业务逻辑层进行处理，具体的业务功能点的实现再继续会委派到领域层去处理，这里我感觉业务逻辑层像是将业务点组织起来的“线”，不知这样假设是否成立，请高手指点：），谢谢
在从用例里抽取领域知识是只是需求分析阶段，往后有些知识是会被遗弃，有些合并，还会发现新的知识点，我觉得好的用例设计应该是能把握住业务领域的需求：），也请高手多指点，探讨，谢谢。：）
Top
7 楼shipp（嘎子）回复于 2005-06-03 21:29:11 得分 0
====“考虑在BusinessUI显示时QueryDlg同时出现在上方，所以有UI组件的关联”
QueryDlg与BusinessUI是独立的么？还是在BusinessUI里需要显示QueryDlg?
意思是：举个实际例子，在点击导航树节点会弹出业务面板，但同时一模态的对话框会同时出现在上方，点击对话框的确定按键后，业务面板会显示查询的数据，不知这样说是否清晰：）Top
8 楼shipp（嘎子）回复于 2005-06-03 21:31:59 得分 0
QueryDlg
{
QueryDlgFacade dlgFacade;
...
}
BusinessUI
{
BusinessUIFacade uiFacade;
QueryDlg queryDlg;
...
}
目前我假设的结构如上。。Top
9 楼taglib（不懂就是不懂，别不懂装懂）回复于 2005-06-04 21:50:16 得分 0
====不是按GUI分类，只是想将表示层同业务逻辑层解耦合，UI组件将需要进行业务处理的数据传递到====业务逻辑层进行处理，具体的业务功能点的实现再继续会委派到领域层去处理，这里我感觉业务逻====辑层像是将业务点组织起来的“线”，不知这样假设是否成立，
我不懂什么叫线，什么叫点，我对BusinessUIFacade/QueryDlgFacade分类的异议在于，为什么要分成BusinessUIFacade和QueryDlgFacade？他们涉及的业务对象完全不同么？还有，为什么要用BusinessUI和QueryDlg作为前置名？而不是AccountingFacade或BusinessInfoLookupFacade?
你讲的都太笼统，没给具体的例子，所以无法判断你的分类是否合理
===="举个实际例子，在点击导航树节点会弹出业务面板，但同时一模态的对话框会同时出现在上方"
====BusinessUI
===={
==== BusinessUIFacade uiFacade;
==== QueryDlg queryDlg;
==== ...
====}
假如你的QueryDlg总是在导航条里跳出，为什么要在BusinessUI里加对它的关联呢？假如QueryDlg也需要在BusinessUI里调用，那么你需要对它添加关联Top
10 楼shipp（嘎子）回复于 2005-06-05 17:15:53 得分 0
我不懂什么叫线，什么叫点，我对BusinessUIFacade/QueryDlgFacade分类的异议在于，为什么要分成BusinessUIFacade和QueryDlgFacade？他们涉及的业务对象完全不同么？还有，为什么要用BusinessUI和QueryDlg作为前置名？而不是AccountingFacade或BusinessInfoLookupFacade?
呵呵，对于UI，后台逻辑处理很少是单个业务对象，基本上上会涉及倒多个业务对象。
名称的命名可能造成了误解：），用**Facade的目的，我只是不想让UI类直接耦合业务对象（我理解应该是领域对象）而添加的一层，不知你是否也只有认为？Top
