程序架构之争

我本不是个好争之人,但在技术上我从来都是表达自己的想法而后快.
记得刚接触一期,我就觉得那里有对头.随着时间的推移,我才感觉到原来是Asp.net程序员在开发的过程常会出现的错误使之(先这样认为).
整个项目采用的是后台实现业务逻辑和数据访问;这就出现的SQL语句和业务逻辑混合在一起的大问题.(会出那些问题呢?)
(1)数据访问出现在后台中,将不得不面对一个数据访问的代码重复问题,在量的相同表操作的语句出现在了功能相近的页面之中.所以当客户需求变动之后(针对单个模块),其它模块会出现连锁问题.这就是代码重复带来的潜在Bug.
(2)数据表设计不符合三范式的要求.可以说完全没有主外键关系.这就出现的一个十分有趣的现在当对不同表进行联合查询时结果不一致.据我估计可能是在开发时少有一种全局的设计,全部以页面来决定数据库设计所致.
(3)业务逻辑在后台中,没有重复的可能.对于业务逻辑的抽象我也没有太多的理解.只是有一些理论.毕竟我也看完了<<企业级架构模式>>的人.呵呵.
二期终于还是来了.面对一期的问题客户也提出了相应的要求.三层开发.
这还不简单呵呵,我暗笑.三下五除二,,把架构建起,写了几个简单的Demo.就这样负责程序架构的事就让我担上了..谁知......在开发第一个实验性的模块时..惨痛的一幕出现了..事务问题..我真的没有想到SQLServer不能外面嵌套事务问题...汗。。。。
第一次感觉到怎么多层程序开发和面向对象的思想这样的不相容...
于是请教了高人...于是我们开发开会讨论...提出以下方案...
(1)在业务层创建Transaction对象实例,,在调用DAL层时把它传下去...我靠,,牛,,
(2)在DAL层需求事务的地方,,用一个事务把多条SQL语句包上..哈哈,,代码重复啊,
(3)Enterprse sevices提供的COM+服务.这个强,,那时候还没搞过.
(4)换开发工具到05,,晕了,,还在用03开发,,原始新人类.(System.Transaction)
开会Ing..我提出了(2)和(3)的方案,,可是最后全被否了,理由是COM+没搞过..(2)垃圾..晕.
最后定的方案是:
Model按表定义,并添加自定义属性,用一个SQL生成工具类来动态的生成SQL语句..想法挺好..
也想快点见识下...
又是一个星期的....准备..
最终我终于见到..大体设计是这样的..
(1)简单的对单表的添加删除修改查询(全部)SQL语句用工具生成.,
(2)重复的查询和业务过程用直接在表示层写SQL语句写,,后向下传.(我的妈...)
(3)事务问题解决办法:把二个Model传入一个函数..在BLL层转换一个DAL在DAL形成一个事务后用工具生成二条SQL语句.(很自豪..事务问题解决了).
个人意见:(不敢明说\说了也没用)
(1)设计思想还是以表为主.这没有错,但用法有问题,,之所以Model用表,就是为了那让那个工具类生成简单的添加删除修改查询(简单)SQL语句,对于复杂的查询等,还是用SQL语句,让人很是不解.期间一点解决复杂业务过程的意思都没有.吐.
(2)对于复杂查询和复杂的业务过程用SQL语句从表示层向下传.啥也别说了..表示层在没用也不能这样用啊,呵呵.
当我提我们能不能把事务的处理层次提高点,放业务层上啊,没人理,,一名话:事务还分层次.我靠,牛比.事务并不是只有Ado.net级别.并不是收集SQL语句到DAL层执行就是解决了事务问题.我们要明白分层的目的,我们的业务怎么抽象,,我们的业务现在不还是混合在SQL语句中,哭死没人管吗?