.Net三层架构--讨论(下篇)

我是提倡分层的,但是,个人认为,一个系统的组成,没有三层那么简单

对于前篇,我的立场没有表达清楚,在此表达歉意,

COM 这个可以说是微软帮助程序员跳出编程噩梦,具有里程碑意义的构想.

Component Object Model,

我更喜欢把它理解为Common Object Model  公共对象模型

每一组对象都作为一种通用解决方案被使用在各个系统中.

有一些解决配置,登录,安全,等业务需求

也有一些解决对象序列化,请求的异步传输,持久化对象,等程序设计需求.

还有些解决UI个性美化方面的需求.

这些对象模型都作为一个独立的体系,被业务层按照自己的规则调用.

 

而业务层,以一个电子商务系统为例,销售,财务,仓储,报表,物流,客户关系等等等,每一个流程都各自可独立成一个业务中间件,

它们是可替换的,可以为其他电子商务系统所重用的.或者添加一个会员折扣的新规则.

如果是单独只是层与层之间的弱耦合,例如: 改变物流关系,会影响到财务的设计.......你一定会被以后接班维护的程序员们诅咒...

 

有时候,为了提高性能,会把一些简单的业务逻辑分散到javascript/client中去,

有时候,将一些难于设计的业务过程,直接写到存储过程.

 这些都是无可厚非的.

忘记三层,尽量去思考哪些功能是可重用的,哪些做法更有利于提高系统性能

减少各个业务流程之间的依赖性.如果你的某个业务环节牵扯到变更整个业务层,无疑,你的设计是失败的.

被频繁访问的请求,尽量少经过几个层次,而直接到达数据库.你的客户永远不会关心你的程序设计是多么的三层.

 

 

后记  

至于我上篇说的那个某某大公司把一切都写到存储过程中去,

我从来没说过他做的对,

公司的现状是应用服务器做了负载均衡,但最终都要访问同一台DBSERVER.

现在搞的老子每天要分析他们的存储过程,提出优化方案,

甚至有可能要把那些存储过程重新设计,放回应用服务器,进行简化后再去DBSERVER进行查询.

如果是一个没有注释,没有数据字典的存储过程,真的很烦