多台计算机上的许多程序使用的DAL框架

时间:2014-01-27 08:51:26

标签: c# database data-access-layer business-logic

在我们的项目中,我们有许多分散在多台计算机上的小程序,每台程序都负责针对遗留数据库的特定任务。今天,它们是用Fortran 77编写的,并使用了一个非常过时的数据库访问框架。

我们正在考虑开始使用C#进行开发,并研究如何最好地创建所有应用程序都可以使用的数据库框架。当旧的实时数据库不支持SQL时,我们不能使用任何现有的框架。

我正在考虑从数据库定义中使用T4生成DAL。 然而,我看到的问题是当数据库发生更改并且必须重新编译DAL时会发生什么。是否足以将包含DAL的dll文件复制到所有计算机,还是我们必须重新编译到应用程序?

数据库的实际结构不会经常变化。但是,很多查找常量会定期更改。通常,不会删除常量,但可以添加新值或添加新值。如果有任何常量被删除,那么正在使用它的程序必须被重写。

我担心它可能会成为一个维护问题,并寻求更好的解决方案。

修改

主键在数据库中不是常量,而是每年重新生成一次。要使程序能够在数据库中找到正确的行,请使用查找常量。在现有程序中,常量直接在代码中以<TableName(RowName)>的形式使用。然后,预处理器将常量替换为当前主键值。这意味着在重建数据库时必须重新编译所有应用程序。

因此,不可能使用例如BLL中的GetByKey(int key)因为关键不是常数。 我看到下面列出的一些不同的解决方案,哪些好,哪些坏?如果您看到其他更好的解决方案,请告诉我:

  • 在DAL中定义查找常量:

    BLL.TableName.GetByKey (DAL.TableNameLookup.RowName)

    • 优点:我在DAL中定义的常量,如果更改了查找,我不必替换BLL。
    • 缺点:详细语法
  • 在BLL中定义查找:

    BLL.TableName.RowName

    • 优点:语法简单
    • 缺点:我必须在更改查找常量时更新BLL。

这可以通过代码生成(T4)和DynamicObject来解决。使用Om DynamicObject,可以在可以轻松更新的XML文件中定义常量。但是,它会明显变慢。

我认为这些方法都不好。请帮我提出更好的建议。

1 个答案:

答案 0 :(得分:1)

在DAL和应用程序之间再使用一层。(例如:BL-Business Layer)

在BL中调用DAL层方法,从应用程序调用BL层。这样做可以避免DAL和Application之间的依赖关系。然后,当您在数据库中进行更改时,仅更改DAL层并替换dll。无需在DAL的每次更改中编译应用程序。