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

【问题标题】：DAL framework used by many programs on multiple computers多台计算机上的许多程序使用的 DAL 框架
【发布时间】：2014-02-18 00:45:08
【问题描述】：

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

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

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

数据库的实际结构不会经常变化。但是，许多查找常量会定期更改。通常情况下，不会删除常量，但它们可以获取新值或者可以添加新值。如果有任何常量被删除，那么使用它的程序无论如何都必须重写。

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

编辑

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

因此无法使用例如GetByKey(int key) 在 BLL 中，因为密钥不是恒定的。我看到下面列出了许多不同的解决方案，哪些是好的，哪些是坏的？如果您看到任何其他更好的解决方案，请告诉我：

在 DAL 中定义查找常量：

BLL.TableName.GetByKey (DAL.TableNameLookup.RowName)
- 优点：我在 DAL 中定义的常量，如果查找更改，我不必替换 BLL。
- 缺点：语法冗长
在 BLL 中定义查找：

BLL.TableName.RowName
- 优点：语法简单
- 缺点：当查找常量更改时，我必须更新 BLL。

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

我认为这些方法中没有一个是好的。请帮助我想出更好的东西。

【问题讨论】：

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

【解决方案1】：

在 DAL 和应用程序之间再使用一层。（例如：BL-业务层）

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

【讨论】：

但如果我理解正确，BL 会返回映射数据库中列的对象。如果列发生变化，从 BL 返回的对象也会发生变化。还是我或者我误解了什么？
您应该将列映射到 DAL。在 DAL 中，您将该映射数据转换为对象。将该对象返回给 BL。 BL 不直接映射到列。如果您更改数据库，那么您应该只在 DAL 中进行更改。因为 BL 仍然需要来自 DAL 的对象。（从 DAL 你必须向 BL 发送相同类型的对象）。然后数据库更改不会影响应用程序。在 DB 中更改后，更改 DAL 以返回 BL 所需的正确对象。
aaa，我有点误解了。没错，我可能可以在程序和 DAL 之间使用 BLL。但是我仍然遇到的一个问题是数据库严重依赖于查找常量。我在这个问题的补充中写了更多关于它们的信息。你对我如何解决这个问题有什么建议吗？
我想你不用担心。因为如果您更新数据库中的查找表数据，您甚至不需要更新 DAL。它会自动获取数据库中存在的查找数据。仅当您更改表结构（设计）时，您才应该在 DAL 中进行更改。
如果我理解正确，程序必须首先从查找表中检索当前主键，然后获取它想要的行。这将创建对数据库的两次访问。在普通的关系数据库中，这已经解决了关系，但是在这个旧数据库中不存在类似的东西。我看到的第二个问题是，如果我将字符串用作常量，则没有 IntelliSense 或编译控制。