项目思路与“自然架构”.doc

项目思路与“自然架构”
三层的思路是要把页面(UI、数据显示)、业务逻辑、数据处理(也叫持久化)分离开来处理,思路自然是好的,但是一到了实际应用中,好多人就会遇到一点小小的问题,于是产生了好多的争论。我觉得一个好的解决方案使用起来应该更容易一些,不应该导致很多人“误入歧途”。所以我觉得三层的分割思路视乎有一点点小问题。
所以我就想了一个自己的分割方式——业务逻辑与代码分离开来!分离之后就要找到一个契合的点,把分开的两个东东在连系起来,这个契合点就是数据库。(我觉得三层的契合点是实体类)
我的具体想法就是:
1、想方设法把业务逻辑(也就是客户提出来的需求)转换成数据库结构。
2、设计数据库
3、实现基本的增删改查、统计汇总、报表打印、导出、审批流、个性化设置等功能。
请注意,第三点里面的“实现”是完全不考虑业务逻辑的,也就是说代码写完了之后可以实现各种行业、各种项目的要求(也就是不同的业务逻辑)。以不变应万变的效果。
【示意图】
怎么样简单吧,如果把数据库看成中心的话,那么左面是业务逻辑,右面就是程序实现(也就是编码)。如果只看右面的话,那就是和业务逻辑无关的,比如说“添加”,就是添加数据,管他是添加产品信息,还是添加员工信息,还是添加请假信息,还是批准一个出车申请,都是添加数据,那么我是不是可以只考虑如何去添加数据,而不用去考虑添加的到底是员工信息还是请假单呢?于是我就弄出来了一个表单控件,这个控件可以实现添加、修改数据的功能,不管是什么样的业务逻辑(客户的需求),只要是添加、修改数据的、单条记录的,那么就可以使用这个表单控件来实现。这就是我的目的。类似的,如果我要查询,那么我可以使用查询控件(还需要分页控件和现实数据的控件来配合),如果我要向导出到Excel,那也可以使用对应的控件来完成。而我在实现这些控件(编写控件的代码)的时候,根本不用去想业务逻辑。当然控件完成之后要拿到具体的项目里面去验证,然后发现不足的地方再去完善,然后在去检验、完善、检验……。不断进行下去。
那么具体的实现方式是什么呢?简单的说就是写一大堆的自定义控件,然后把这些控件有机的联系在一起。
图片看不清楚?请点击这里查看原图(大图)。
上次说了,显示数据的控件+ QuickPager + Pager_SQL + essLibrary + 数据库,
就是一个分页的解决方案,再加上查询控件,就可以实现分页和查询功能。
那么同理,表单控件+ Insert、Update的封装+ essLibrary + 数据库,
就是一个单条记录的添加修改的解决方案,再加一个控件就可以实现多条记录的批量修改。
列表和表单结合起来,就是主从表的维护。
还有数状结构的功能节点、按钮组、导Excel等控件,这些控件结合起来就可以完成三分之一以上的功能,还有权限管理、个性化设置,一些小的项目就可以横扫了。我还没有做过大项目,可能到了大项目里面,我的这些幼稚的想法就不适合了,但是我有信心,只要我接触了大项目,那么我就会利用我在大项目里面了解、体验、掌握到的经验来完善我的这个想法。因为我就是这么一路走过来的,我想我还没有走到终点吧,呵呵。
自然架构
自然架构,自然而然,水到渠成。
信息管理——信息——数据——数据库——关系型数据库。