我正在编写一个应用程序,其中包含各种表单和相应的数据模块。
我以这样的方式编写代码,即通过在uses类中引用彼此(一种在实现中,另一种在接口中,以避免交叉引用)来实现它们之间的使用。
这种方法是否错误?为什么或者为什么不应该这样使用?
我正在编写一个应用程序,其中包含各种表单和相应的数据模块。
我以这样的方式编写代码,即通过在uses类中引用彼此(一种在实现中,另一种在接口中,以避免交叉引用)来实现它们之间的使用。
这种方法是否错误?为什么或者为什么不应该这样使用?
我必须同意Ldsandon的观点,我认为在项目中拥有多个数据模块比较好。如果你将其视为模型-视图-控制器,则DB是模型,表单是视图,数据模块是控制器。
个人而言,我在项目中至少有2个数据模块。一个数据模块用于在整个项目中共享操作、图像列表、DB连接等其他内容。大多数情况下,这是我的主要数据模块。
从那里开始,我为应用程序中的每个“实体”创建一个新的数据模块。例如,如果我的应用程序需要处理或显示订单、客户和产品,则我将为每个实体都有一个数据模块。
这样,我可以清晰地分离功能,并轻松地重复使用一些部分,而不必拉入所有内容。如果我需要与客户相关的内容,我只需使用客户数据模块即可。
问候,
Stefaan
没问题,特别是当你需要创建多个使用不同相关数据模块实例的相同表单时。
只需注意VCL设计中的一个小问题:如果创建两个相同表单和它们的数据模块实例,除非在创建数据模块实例时使用一些小技巧,否则这两个表单将指向同一个数据模块(由于VLC解析链接的方式):
if FDataModule = nil then
begin
FDataModule := TMyDataModule.Create(Self);
FDataModule.Name := ''; // That will avoid pointing to the same datamodule
end;
如果您只有一些数据库表,则为您的表对象创建一个数据模块是不错的选择。
而为您的操作创建一个数据模块则是另一个好的选择。
为图像列表创建一个独立的数据模块也是不错的选择。该数据模块仅包含图像列表,需要访问图像列表的表单可以从这个共享位置使用它们。
如果您有200个以上的表对象,则可能需要不止一个数据模块来处理它们。假设有一个涉及20个发票表和另外20个人力资源表的应用程序,如果它们内部的表格和代码不需要相互了解,或者即使其中一个模块在一个方向上具有"使用"依赖关系,但关系不是循环的,那么一个 InvoicingDataModule 和 HRDataModule 可以很好地分开。即便如此,更细粒度的数据模块划分也可以带来益处。