gudu0723

如何才能称之为业务逻辑与界面达到了彻底的分离？回答这个问题困难。但是如果能够找到一个参考原型，那就会很好理解。

我找的一个参考原型是：SQL Server + SQL Admin

1、SQL Server是服务器，它只有业务逻辑，没有界面；

2、SQL Admin是SQL Server的界面，没有业务逻辑；

3、SQL Server与SQL Admin通过TCP交互，它们是彻底分离的，影射成就是：这是一种业务逻辑与界面彻底分离的完美形式；

他们是如何彻底分离？其实很简单：

SQL Server提供了SQL Admin的一个TCP命令调用接口，也就是Command模式来完成，影射成就是：程序的业务逻辑应该提供给界面一个Command接口，界面只能够通过Command接口来执行命令，而不能直接操作业务逻辑里面的数据。

当然，如果考虑到界面需要不挂起，若Command执行是阻塞模式就有些问题，需要变换成回调返回的异步模式，这会复杂少许。

最终还是发现，将粗的类拆分开来，成为，One Funcation------One Class的小类模式， 降低了复杂度，较之前者，效果好很多。原因：

1、小class模式，让人的关注点集中了，关注并作好一个小class容易许多；

2、小class模式，让一个类的代码不会那么多，容易查找，修改；

3、分来开来后，关注减少，更不容易引入错误，把功能拆封到人的思维能力能够控制的规模之内。

1、对于界面之流，他要Get什么和如何Display我不管，可以给它对象和接口，他可以自己组合成自己的显示，显示永远都不是业务逻辑的部分;

2、对于界面之流，他要Change什么我要管，不能让他调用能够改变模型的接口，因为改变肯定是业务逻辑的部分，界面中直接调用方法来改变，意味着业务逻辑存在耦合到界面中的部分，这是不允许的。

3、总结，任何Change都必须通过UserCommand，让UserCommand这个抽象层来完成这个事情，一个参与者会有一系列的命令接口。

==============================================================================

备注：后来的一点领悟，任何改变和执行都是业务逻辑的部分。如果能够确保界面只能够调用Get?，可以通过const来解决。

a、界面得到一个const object* 或者const object&;

b、const对象或者指针，只能调用const方法，const 方法意味着no change

1、一个大的类，拆封成小的类，有没有效率损失？答案是没有的，因为类的本质就是提供接口，进行函数调用。一个大类包含100个函数，与分解成10个小类，每个10个函数，在效率上没有差别；

2、小类模式，会不会增加复杂性？答案是部分增加，部分降低。小类模式增加了类的个数，一个项目抽象体越多，复杂度越高，这不容置疑，所有者一部分增加了复杂性。另一方面小类模式，表明一个类只完成需要的功能，所以在层次划分上更加的清晰，这在一个层面上降低了复杂性。

观点一：深度带来复杂性

模式1为5级深度，模式2为2级深度；

观点二：深度带来耦合

模式1中，A耦合了BCDE, B耦合了CDE, C耦合了DE，D耦合了E, 耦合数目为：10；

模式2中：控制器耦合了ABCDE，耦合数据为：5。

观点三：串联改并联，提取控制逻辑到独立模块，减低复杂度。

1、不能从算法和数据结构的组织这个层面上考虑设计，而应该从从模块和数据流的层面上考虑设计。把数据流搞清楚，按照需求，拆分成能够完成需求的各自独立的模块，让数据从起点到终点流动，被处理，最后得到结果。

      比如：数据存储模块、价格发生器、价格过滤器、交叉盘价格合成器、价格发布器、视图模块；

2、根据数据流图，拆分出来的独立模块，设计类；

3、类的分别原则是：属于流程不同模块，即使功能相似或者相近，也不能合成一个类；

4、一个类只做有限的事情，大而全的类虽然有可能是一种方案，但决不是最好的方案，它增加了耦合和复杂性，维护性也很低；

5、类的实现部分，尽量不要直接调用类成员以外的数据，比在类的函数中，直接对某个全局对象调用方法，这样类函数执行的前提是：这个全局对象必须存在，而这是一种耦合。解耦是简单的，那就是把这个全局对象作为类函数的参数传入；

6、类的方法接口，应该只接受能够完成类方法所需要的数据，如果传递一个指针，这个指针包含的内容，可能远远超过类方法所需要的；

7、关于上一点的解决办法是：构建类需要参数的POD，不要怕转换，不要怕生成临时对象，事实上我需要这样做。

===========================================================================================

改进后的版本

1、界面视图本来可以承担控制器的作用，也就是MVC简化成MV。但是这样就必须让视图来处理命令，试图必须具备双向的能力：即解析命令，并向下执行同步到模型（数据)；根据模型（数据)，同步视图，向上更新界面；

2、控制器和视图集中在视图里面，增加了视图的复杂性，如果增加一个命令控制器，最终变成MVC，那么视图就只需要具备向上更新UI的能力，向下执行命令更改模型（数据)的能力交给了命令控制器。这样就实现了一上一下，各司其职的架构；

3、形成视图的经常不只是一种数据流，往往多种数据流共同形成一个视图：比如下面的结构中，视图是由：配置流，价格流，日志流三种组合而成的；

4、增加命令控制器的作用的事显而易见的，它让业务控制的接口可以脱离视图而存在。反过来理解，如果用视图来同时充当用户命令接口，那么用户命令接口存在的前提是视图必须存在。而视图是多变的，或者说可以根本不存在，那么把用户命令接口放在其中极其不合适。试想一下，一个项目它可以是个对话框，可以是个多文档，也可以是个控制台，多变的界面，多变的视图，但是用户命令接口确实不便的，把用户命令耦合到视图的实现里面去，就不合适了；

5、把命令控制器抽离出来的另一个好处是：集中管理用户的命令，便于维护。试想一个如果对用户命令的处理分散在若干个.cpp文件，几十个C***Dailog的On***Button()消息相应函数里面，理解，调试，维护起来，将是一件多为痛苦的事情；

6、更多想写的一句话，就是业务逻辑，不要和界面耦合起来，界面需要做的就是：显示视图，接受用户命令两个功能，其他的都没必要在界面里面存在。举个例子，用得很多的MFC OnTimer()函数，事实上定时操作应该是业务逻辑的部分，放在界面里执行就不合适了；

7、检测界面与业务逻辑耦合程度的一个标志就是：把程序里界面代码剥离后，业务逻辑依然完整，程序依然可以运行。如上面所说的，界面中处理OnTImer()函数，则去掉界面代码后，业务逻辑就不完整了，少了执行定时业务处理的部分，这就是一中明显的界面与业务逻辑耦合。

8、程序可以分为很多功能模块，命令控制器能够控制这些功能模块的行为是应该，这些功能模块输出信息到视图里面也是应该的。

===========================================================================================

struct ViewResult
{
    struct ViewSource
    {
        char  symbol[12];
        int        digits;
        double minprice;
        double minspread;
        double peerminm;
        BOOL    usepremium;
        double premiumex;
        char   session_current;
        char    remark[256];
        BOOL   session_enable;
    } view_source;
    struct ViewTrans
    {
        BOOL   b_bid_success;
        BOOL    b_ask_success;
    }view_trans;
    struct ViewPrice
    {
        double bid;
        double ask;
    }view_price;
};

    BOOL UpdateViewSource(int index, const ViewResult::ViewSource& vs);
    BOOL UpdateViewTrans(int index, const ViewResult::ViewTrans& vt);
    BOOL UpdateViewPrice(int index, const ViewResult::ViewPrice& vp);
    BOOL UpdateViewMsg(const ViewMsg& vm);
p

需要把自己的代码，和得到的代码整理起来放到一个称之为“my self”库里面；

到处拷贝，粘贴绝对不是一个好的办法，保存一个备份，而不是多个备份；

只有一个备份，也就意味着代码需要达到通用级别的复用，不知不觉，你的设计就会改善。

QUOTE:

原帖由 "albcamus" 发表：
我感觉那种遇到大型项目问题，觉得目前的开发环境不够完美，从而为此设计一种语言的，都是顶尖级的牛人。一般?.........

最近新闻:面向语言的程序设计.

QUOTE:

借助工具的帮助，允许开发者创建自己的DSL。这样的DSL当然能够最贴切地描述领域问题，从而大大提高开发效率。

[quote]原帖由 "aero"]那种为项目开发语言的事情，应该是计算机的传说了吧。感觉现在，语言足够了。[/quote 发表：
“为项目”确实太奢侈了。
不过好的通用产品大多都有一套自己的脚本语言。
毕竟单纯的 .ini 配置文件的功能太弱了，
不能适应客户们无穷无尽的需求。
因此，要想做一个通用的、面向各种客户的产品，
必须要把业务有关的部分从核心里边剥离出来，以便于灵活配置。
我这段时间就天天在编这种破脚本，烦死了。

1、函数就是一个模块，必须独立；

2、尽一切减少关联，降低耦合；

3、努力不要调用其他对象，变量，仅仅完成自己的功能，如果要调用，应该作为变量传入；

4、一点涉及到与具体应用相关的对象，那么这个源码的复用就是一句屁话。

5、函数的调用规则应该是控制逻辑里的事情；

6、耦合的模块很难进行自动化的单元测试。