关于界面和业务分离!! (50分)

  • 主题发起人 主题发起人 razy
  • 开始时间 开始时间
R

razy

Unregistered / Unconfirmed
GUEST, unregistred user!
今天看了刘艺老师的《Delphi面向对象编程思想》示例程序中的界面与业务分离。里面用DataSetProvider来提供数据,ClientDataSet来接受数据。觉得用户界面获取数据时有些问题。比如在查询数据时,如果是一个查询字段,可以写一个函数获取数据,如果是两个查询字段,又要写一个函数,而且在查询条件里可以用=、〈,〉,between等很多操作符,是不是又要写很多函数?因为一个系统不太可能是一个表组成的,查询的时候肯定有很多变化!!
但是如果这样的话,界面一变,那些函数很多也要变啊!!那界面和业务分离有什么好处。还不如你直接写在界面里了!!
 
一般的做法是写业务类,然后由界面进行调用,这样,界面就不用变了.
 
上面也是用业务类来实现的啊!!类里面包括了获取数据的函数!!
说直接一点吧!!
界面与业务分离后是怎么进行查询的?是每一种查询(查询条件不同)都在类里写一个函数
呢,还是怎么样?
 
进销存,ERP之类的程序,80%以上的代码都是用来跟界面打交道的,都是怎么引导,控制用户输入的代码,业务处理类的代码简直太少了,感觉做这类程序界面和业务分离效果不大。
 
我感觉就是作成三层,作成COM+,客户端程序代码一点也减少不了多少。
 
中间层的业务对象也是要进行类封装的。至于查询业务对象的查询方法要充分考虑各种条件后再定义。关于很复杂的查询,现在也找不出什么一致的方法,实在不行就把SQL在客户端拼装后在交给中间层执行吧。
 
想知道答案的 请买修订版/加强版 据说刘老师正在写作中
 
业务和界面分离有时很难实现啊。
 
最大的问题在于,如何设计出do
main model.
 
“在查询条件里可以用=、〈,〉,between等很多操作符,是不是又要写很多函数?”
--写个比较通用的查询
“但是如果这样的话,界面一变,那些函数很多也要变啊!!那界面和业务分离有什么好处。还不如你直接写在界面里了!! ”
--如果我要通过人员代码查询人名,可以这样:
function GetNamebyCode(PersonCode) : string;
如果在一个比较大的系统中,“通过人员代码查询人名”可以在多个界面使用。这是不是好处?
有本《windows DNA 可扩展设计》,讲了一些设计权衡,可以看看。不过提前说一声,翻译的不好,代码是VB的。

 
业务和界面分离有时很难实现啊。是的!!!!
没有绝对的,就是oop,也不一定好!没有类有是比使用类还好
 
后退
顶部