创建数据访问对象时最佳方法是什么？

Question

我在 MyWebpage.aspx.cs 文件中有一个方法:

public partial class MyWebpage : PageBase
{
    private readonly DataAccessLayer dataAccessLayer;

    protected string GetMyTitle(string myVar, string myId)
    {
        if (string.IsNullOrEmpty(myVar))
        {
            return string.Empty;
        }

        return dataAccessLayer.GetMyTitle(Convert.ToInt32(myId), myVar);
    }
}

在DataAccessLayer类中，我有一个方法用于与数据库交互并完成DAL操作并返回标题。

关于从MyWebPage.aspx.cs类访问DAL的最佳实践是什么（例如，每次都需要创建新的DataAccessLayer()对象吗？在哪里应该在我的PageBase类中创建它还是每次在代码后台调用时创建它？）。

- cdub

Answer 1

首先，从代码后台或演示层访问数据访问层（DAL）通常不是一个好的实践。因为在这种情况下，您需要将业务逻辑代码放在您的代码后台（演示层）中，这会导致关注点混淆、高耦合、重复等问题。因此，如果您正在寻找最佳实践，建议查看以下链接：

• 数据层指南
• 分层应用程序指南
• 对象关系元数据映射模式（特别是仓储库模式）和领域逻辑模式

而且这些书非常好：

• 企业应用体系结构模式（Martin Fowler著）
• Microsoft® .NET：面向企业架构的应用程序设计

此外，关于在DAL中使用静态函数进行调用。正如您所知，静态函数容易受到多线程的影响，因此如果您在DAL函数中使用了任何共享内容（有时会出现这种情况，例如共享连接、命令等），它将破坏您的代码，因此建议避免在此层中使用静态函数。

- Cyrus

Answer 2

我是仓储模式的粉丝。每个人都有自己的看法，但我喜欢一个SQL表=>一个仓储库并共享名称的想法，就像ORM工具一样。

Entity Framework可以快速处理您的数据访问层（DAL），您仍然可以实现类似于仓储库的DAL模式。

这里有一个代码生成器，它需要一个SQL连接字符串，并提供了一个相当标准的企业数据访问应用程序块实现。它不是非常强大，因为它是针对一个平淡无奇的SQL架构设计的。如果您使用示例数据库，它将为您提供可用于设计自己喜欢的数据访问层的代码示例。

- TheDev6

---

每个存储库一个表 - 但是如果您更改数据库结构会发生什么？ - John Saunders

你有什么模式建议，不需要在数据库更改时进行修改？ - TheDev6

使用类似于Entity Framework的工具在概念层面上进行建模，并使用映射层将其映射到物理数据库结构。这样，业务层就不需要知道特定实体是在一个表中还是在三个表中实现。 - John Saunders

合理的建议。然而，如果数据库发生变化，您仍然需要至少更改映射层，因此当数据库发生变化时应该更新C#（或EF模型）的答案仍然是正确的。我喜欢数据库表是业务对象的良好表示，但总有例外和充分理由来偏离这种规则。 - TheDev6

是的，它需要代码更改。如果您在不更新映射的情况下删除列，则实体将中断。即使它发生在向导内部，我也认为这是一种代码更改。 :) - TheDev6

它发生在向导中或XML中，但是映射元数据的更改是唯一需要更改的内容。无需更改C#代码。 - John Saunders