这里,好多新人加入我们团队的时候就好奇这个事务居然不要在数据库中写,这个在后面的篇章中再详细讲,总而言之我们遵循一个原则:
数据库的职责是做存储数据,我们尽可能不去把业务逻辑放在数据库中去处理。
这里还出现了Alert()方法,这个也是从FacadeBase中继承而来,在调用业务Facade的时候,我们可能直接拿出Facade业务对象返还的Message错误信息。
在后期的项目篇章中这个Alert() 会出现很多。
另外,这里我们也有一个写Facade业务的基础思想“水渠思想”,就像河水变成自来水的过程,要经过多到工序,有一步有问题我们就结束。
所以,我们就一层层的判断。 但不是 用嵌套if去写, 而在if判断为false之后 直接return,为true 就执行下一步。
(好比:“河水过滤失败,不能进行下一步,返回。过滤成功,下一步开始杀毒,杀毒失败返回,杀毒成功,开始氯洗····一直到最后成功”)
中间每一笔以事务管理起来,失败就RollBack(),成功则Commit()。
====================华丽的分隔线=====================
项目 显示层:
最后的显示层,以前我们用的是Asp.Net,我们会有TopPageBase基类 和 CommPageBase,TopPageBase没有验证登录信息,
是给不需要登录的界面继承的,而继承了CommPageBase 的页面则必须要登录。 当然还有相应有很多前端插件,比如分页控件,日历控件等等。
但是现在.net主要都是使用 .net MVC了。 所以我们单独也有一个程序集 Winner.FrameWork.Mvc.dll。
如下图:
自此也Winner框架的解决方案也就描述的差不多,我们前端没有形成自己的一套JS库,更多的还是使用第三方库。常规的JQuery 和 KnockOut
我就不再做描述,这方面我个人也用的不好,在这方面Jason和阿jie 都非常厉害。
遗憾的是Winner框架 没有形成一套Winner前端的后台模板。相对Ace UI模板用的比较多,另外 Amaze UI 也有一些。
阿杰说他有写一套前端,目前在团队内部推广。如果没问题,我也希望Winner有自己的一套前端这样也能省很多事。
不过,我的终极想法是,代码生成器能直接生成前端,这样就更省事了。
好吧,关于解决方案的命名和结构就写到这里。
来源: http://www.cnblogs.com/demon28/p/7905369.html