一般Mis系统的业务逻辑复杂度之自我体会

      以前对就光听说要根据业务逻辑的复杂度来划分不同体系架构.刚也看了MSDN上的一文章,逻辑分层觉得很有道理,我们总是将习惯变成真理.就那三层体系结构来说,它不并不适用所有的项目,如果你的项目有的只是对数据的记录,说白了就是CURD操作,那Table Model模式就能完全的组织好你的业务逻辑,并且要特别的注意一点,那就是你的程序跳跃组件而这些组件放到不同的机器上时,那性能上的消耗是十分的惊人的.还有一点如果你们现在的实力不能合理的划分业务对象(领域模型)那最好还是用Table Model来组织,因为那样最少在业务不是很复杂的情况下,对表一级的操作将带来很好的重用.
      就拿我们现在的项目来说,业务逻辑集中在以CURD为主,客户要求用三层体系来开发,没有提出要部署到不同的机器上(谢天谢地);而现在的解决方案是用业务对象组织业务层,但业务对象的划分上我觉得还是有点问题(在业务一级的征用上没有,表一级的也没有,呵呵 不知道怎么组织的),最严重的一点是,把本该由业务层组织的逻辑下放到DAL层(当然这样做有一定原因,首先我们用的是03,并且没有引入EnterpriceService),但从项目的进展来看,不是十分的理想,我一直试图找到原因,总结如下:
1)业务层少有一个能把握全局的人来把握,并且也少有整体性的讨论.
2)事务下放带上整体三层体系上的职责划分的混乱.
3)VSS管理工具用的不是很熟悉(之前把BIN目录和Debug目录全管理起来了,并且不能对他们的写权限,可想而知肯定会出现许多莫明的问题).
4)一些页面特效的实现上,如DataGrid合并行,DataGrid嵌套等.
      唉,,,,像这样的业务这么单一的项目,就算用业务对象组织业务逻辑,也不会变这么一团糟。