探讨，如何实现最大限度的软件复用

李啸林

经常写数据库程序，很容易碰到类似的问题。人总是喜欢偷懒的，以前已经写过的代码，我是不愿意重新再写一次。COPY 也许是一个解决的方法。但还是有许多时候，依靠COPY很难解决的，即使解决也仍旧还有不少麻烦。

大概在二年前，小七的网站（ACCXP）里，我曾经提出一个组件开发的概念。但如何去实现那时候心里还是很模糊的。今过这几年的思考，我有一个思路，今天写下来，大家看看如何。

第一步：数据库系统的一般应用窗口。应该分为三个部分。

     第一个部分：界面显示组件。

     第二个部分：业务逻辑处理组件，供第一部分调用。

     第三个部分：数据查询存储组件。供第二、第一部分调用。

第二步：制定数据源标准。

     我们只需要根据数据源标准，进行界面设计就可以了。并且还可以根据同一标准，设计不同的显示界面。

    同理，数据查询存储组件只需要根据指定的查询条件，返回符合标准的数据即可以了。这样子就可以消除对具体数据库的依赖。

    同样，业务逻辑处理组件只需关心它从数据查询存储组件得到数据是否符合标准即可，它不用去关心数据是如何存储的，这就把业务逻辑对表结构的依赖所取消。

第三步：设计数据查询存储组件

    到这里，你也许会问查询存储组件是如何解决数据库依赖与表结构依赖？

    道理很简单，先根据数据交互标准，先设计出一个抽象的查询存储类，接着再根据这个抽象类设计ACCESS实现、MSSQL实现、或者是ORACLE实现。

第四步：设计业务逻辑部件与界面显示部件。

    这是很容易理解的，我就不展开说了。

关键点：必须小心谨慎地设计数据源、数据交互标准。

fan0217

赞同：从宿舍到食堂，自行车比小汽车作为代步工具更加合适。

李啸林

wrest,你好。小七已经许久没消息了。唉，时间真快。

你说得完全正确，Access不太适合采用这种方式。Access最适合得微型、小型系统得快速开发，并不适合大中型系统。

Access本身就定位于桌面数据库，强行让Access去完成它不善于的任务，到头来很可能会大费时间。

打个比方，从宿舍到食堂，自行车比小汽车作为代步工具更加合适。永远都不要去比较Access与SQL谁优谁劣。

仔细搞清楚自己包中七种武器的特点，根据具体场景挑选最合适的武器，去解决问题。

我个人认为（并不准确），用ACCESS去实现一个月内就能完工的系统是最适合的。

wrest

大概在二年前，小七的网站（ACCXP）里，我曾经拜读过LZ一篇关于组件开发的帖子，颇有同感。


呵呵，没想到两年后，又在这里看到了LZ的后序。





我是先从VB、VFP这些工具入手编程的，几年后，接手了一个外国客户的业务，才开始了解Access和VBA开发的。Access的优点也的确让我“触

目惊心”。但是在开发过程中，种种的限制又让我觉得很不舒服，“偷懒”的思想让我和LZ一样去思考，如何有效利用以前的成果来服务于现在的项目。在使用其

他开发工具（如JAVA，.net）的人员中三层架构在开发思想中已不是什么新鲜名词，解耦合和接口在OOP领域已成为基础知识。说到这里，提出一个问

题，那就是如果采用了这种方式，Access对我们来说，除了窗体开发的便捷，又有什么呢？

老鬼

真的很有道理，像我等编程低手，就动不动重复写程序，又觉得累，呵呵~~~~

李啸林

以下是引用xinbao在2005-7-24 10:46:00的发言：

很有道理,难题是如何平衡通用与具体的需求,不可能百分百通用,但又不能全部定制

你说得很对。如何把握好通用与具体之间的平衡，确实是一个需要仔细衡量的问题。

我想百分百的复用是不现实的，也没有意义。我只是想在我们做设计的时候，应该多为以后的代码复用与重用多考虑些，尽量多做一些可重用的组件，这样的话，即使本次项目失败，亏了，但在本次项目中开发出来的代码，还能够被以后项目重新使用，这不是可以节约成本吗。

xinbao

很有道理,难题是如何平衡通用与具体的需求,不可能百分百通用,但又不能全部定制