问题 不同逻辑层上的接口

如果我正确理解了这个问题，那么您已经创建了一个域模型，并且您希望编写一个对象关系映射器来映射数据库中的记录和域对象。但是，您担心使用“管道”代码来污染您的域模型，这些代码是读取和写入对象字段所必需的。

退一步，您基本上有两种选择，可以放置数据映射代码 - 在域类本身或外部映射类中。 第一个选项通常称为Active Record模式，其优点是每个对象都知道如何持久保存自己并且对其内部结构有足够的访问权限，以允许它执行映射而无需公开非业务相关字段。

例如

public class User
{
    private string name;
    private AccountStatus status;

    private User()
    {
    }

    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    public AccountStatus Status
    {
        get { return status; }
    }

    public void Activate()
    {
        status = AccountStatus.Active;
    }

    public void Suspend()
    {
        status = AccountStatus.Suspended;
    }

    public static User GetById(int id)
    {
        User fetchedUser = new User();

        // Lots of database and error-checking code
        // omitted for clarity
        // ...

        fetchedUser.name = (string) reader["Name"];
        fetchedUser.status = (int)reader["statusCode"] == 0 ? AccountStatus.Suspended : AccountStatus.Active;

        return fetchedUser;
    }

    public static void Save(User user)
    {
        // Code to save User's internal structure to database
        // ...
    }
}

在此示例中，我们有一个对象，表示具有Name和AccountStatus的用户。我们不希望允许直接设置Status，可能是因为我们要检查更改是否是有效的状态转换，因此我们没有setter。幸运的是，GetById和Save静态方法中的映射代码可以完全访问对象的名称和状态字段。

第二个选项是有一个负责映射的第二个类。这样做的优点是可以分离出业务逻辑和持久性的不同问题，从而使您的设计更加可测试和灵活。此方法的挑战是如何将名称和状态字段公开给外部类。一些选项是：   1.使用反射（没有任何关于深入挖掘对象私有部分的疑虑）   2.提供特别命名的公共制定者（例如在他们前面加上“私人”一词）并希望没有人意外地使用它们   3.如果您的语言支持它，请将setter设为内部，但授予您的数据映射器模块访问权限。例如。使用.NET 2.0以上的InternalsVisibleToAttribute或C ++中的友元函数

有关更多信息，我建议使用Martin Fowler的经典着作“企业架构模式”

但是，作为一个警告，在开始编写自己的映射器之前，我强烈建议您使用第三方对象关系映射器（ORM）工具，如nHibernate或Microsoft的Entity Framework。我参与了四个不同的项目，由于各种原因，我们编写了自己的映射器，很容易浪费大量时间来维护和扩展映射器，而不是编写提供最终用户价值的代码。到目前为止，我已经在一个项目中使用了nHibernate，虽然它最初的学习曲线非常陡峭，但你早期投入的回报却相当可观。