没头没尾--项目开发笔记：面向业务的用户界面与面向对象的数据库如何连接

标题：没头没尾--项目开发笔记：面向业务的用户界面与面向对象的数据库如何连接

关键词：分布式开发 C# 项目分工 面向对象的数据库设计 面向业务的用户界面

       11月21号：新的一天又开始了

接着昨天的写吧。现在来谈谈面向业务的用户界面与面向对象的数据库应该在框架中如何进行连接吧。

先把我定义的面向业务的用户界面与面向对象的数据库的组织方式说一下。

l         面向业务的用户界面：用户操作系统中，往往是根据系统一共有几个大模块，然后是模块下面具体有什么业务来进行组织的。例如系统中有

n     采购模块

u       开采购单

u       作采购计划

n     销售模块

u       开销售单

u       结算

l         面向对象的数据库设计：一看就知道了,数据库的设计一定是按面向对象的设计方法,用XX范式之类的东东。例如系统中会有

n     机构表

n     商品表

n     单据表

好了，如果这两边都搞定了，那么一定是要在我们的系统把这两块联系起来（废话）。那我去怎么考虑联系两边的呢？

先回忆一下我以前是怎么搞的吧。用VC或VB写程序的时候，我们可能直接从界面中写连接数据库的逻辑，那么设计的实现也就是变成从界面到数据库是采用混和的模式写程序（想想头也大，还好现在不要这么去写）。进一步到JAVA的分层开发，有DataObject,BusinessObject,UI三层，结构上DataObject,BusinessObject描述的东东从内容上是一样的，基本上是对数据库，也就是对象的封装。只有在界面层的时候才是对业务的封装。可以JAVA的分层没有现在这么复杂。比如我们会有很多的不同的Client实现方法，这些方法可能是按照不同的业务方式进行组织的；又比如我已经写了一小部分框架与代码的自动生成工具，自动生成工具的原理就是对几个组织结构相同的部分可以进行相同的代码文件生成。以方便人员分工（代码生成工具的事回头再和大家说）。这些都需要在一开始就考虑好是统一的在什么层进行两种关系的接口。

好了，上面罗罗嗦嗦一大堆，是我在与部门同仁讨论时说的，最后的结论是把这个分离的事放在facade层来做。也就Business Rules还是按照对象的方式来组织。Facade按业务的方式来组织。Facade对界面中的结构化业务是一一对应的，有一个销售的业务模块就会有一个SalesBillFacade与之对应，而Rules与数据表在代码生成之初是一一对应的，有一张SalesBillTable就会有一个SalesBillTableRules与之对应。对这两边的对应修改原则也是按业务与对象的划分来定义的。如果要加入对数据对象的操作，比如查询，修改数据。一定是要business rules中加方法，然后一直调用到数据库；如果要加入业务上修改，比如要把销售单中的结算与进货单中的结算合并成一个新的结算模块，那调整的就应该是facade层了，别的不应该动。这是条原则。

上面是我的项目中采用的一条原则的前因后果，没有什么必须的约束。大伙有什么好的想法也可以拿来交流，下一节将会写一些上面总结之后胡思乱想的东西了，大伙也可看可不看。（只要不骂娘就好!J）