本人最近头痛于一个windows代码问题。
就是在form所属unit中代码也太多了。
于是想到了有关界面与代码分离的话题,想请大伙儿探讨探讨。
代码和界面如何分离?
当代码中含有界面里的控件时分离好像就没有想象中那么简单了。

解决方案 »

  1.   

    DLL,数据库后台编程。控件。
    不过C/S没必要啊。这是B/S需要考虑的问题吧。
      

  2.   


    procedure Draw(ACanvas:TCanvas);
    begin
      ACanvas.draw();
    end;
      

  3.   

    你可以把控件指针当参数传递。例如:  FGrid: TStringGrid;
      FTreeView:TTreeView;Create的时候就这样
     MyClass.Create(AGrid:TstringGrid,ATreeView:TTreeView);
      begin
        FGrid := AGrid;
        FTreeView := ATreeView;
       .........
      end;通过 FGrid.Cells[i,j] := MyString;
         MyNode := FTreeView.Selected 来对界面元素进行操作。
      

  4.   

    我一向希望自己的程序能做到界面unit 与 代码unit 相分离。
    但是,事实上,一般界面unit 中还是很乱。
    比如,Label.Caption Edit.Text的赋值都是在界面unit 中完成。
    真正的所谓归类为“代码”的真是不怎么多。
    所以,看看大家,在对待这个话题时,都是怎样来处理个中的关系。
      

  5.   

    看看设计模式行里面的command模式
      

  6.   

    数据和代码紧密结合好像是面向对象编程的实质;
    如果你嫌一个form的代码较多,可以多分几个,有些form可以不显示,只是用来归类。
      

  7.   

    N言难尽呀
    http://expert.csdn.net/Expert/topic/2932/2932964.xml?temp=.259411
      

  8.   

    http://expert.csdn.net/Expert/topic/2932/2932964.xml?temp=.259411
      

  9.   

    在另开unit里写成类吧,在form命令里调用,这可不是个轻松的事儿
      

  10.   

    我的看法是,能写成函数和类的,决不让CODE夹杂在事件相应中,一个程序肯定要公用UNIT
      

  11.   

    不要走极端,跟界面关系密切或者只是几行的的代码分离出来反而会让自己以后觉得很乱。
    跟界面没直接关系的,比如纯计算问题、数据库稍复杂的操作当然分离出来比较好。不管怎么分离,界面单元中总是会有一堆OnClick之类,自动生成的框架就要占好多地方。如果本来代码就简单,重复就重复吧、该粘贴就粘贴吧。分离出来也还是会占那么多地方,虽然实际代码就一个调用。