0

这不是一个有明确答案的问题，但我需要一些关于我的架构的建议。关于这个话题可能有很多不同的意见。

我正在尝试将我的架构从愚蠢的实体转移到丰富的领域对象。在我当前的版本中，我有抽象的域对象，它们具有代表业务逻辑的只读属性和方法：

abstract class Project
{
  public string PropertyName { get; protected set; }
  public void Setup(SetupData data)
  {
    ...
    Save();
  }
  protected abstract void Save();
}

我从它们派生来实现到持久性实体的映射并实现保存逻辑：

class MongoProject
{
  MongoProject(ProjectDocument document, Action<ProjectDocument> save)
  {
    MapFrom(document);
  }
  public override Save()
  {
    MapTo(document);
    save(document);
  }
}

这很容易工作，该项目始终有效，因为它没有公共设置器并且可以测试，甚至与文档的映射。

但我也意识到了一些问题：

  1. 我总是忘记映射一些属性，没有办法告诉 MongoProject 它必须序列化什么。
  2. 有时实现映射相对复杂，因为您不知道 save 方法内部发生了哪些更改，尤其是在项目是复杂聚合根的情况下。在我的情况下，使用 mongodb 实现持久性非常容易，但对于实体框架来说却是一场噩梦。

您如何解决应用程序中的持久性问题以及映射问题是否有其他解决方案？

4

1 回答 1

0

这是一个有点宽泛的问题。

我从来没有在同一个类中实现我的域对象和我的数据访问层（保存到数据库、文件、云等）。需要分离关注点。您的域对象不必知道如何将自己保存到数据库中。

我要做的是在一个类中创建我的域对象，并创建一个单独的数据访问层，它负责将我的数据保存到我希望将其保存到的任何源。这样，每次您想将实体保存到不同的位置时，您的对象模型并不关心，您根本不必更改它。

要将 POCO 对象映射到 DB 实体，请使用AutoMapper，它将为您节省大量样板代码，您只需配置一次

例如：

// Domain object
public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

// Data Access Layer
public class MongoAccessLayer : IDal
{
    public void SaveEntity<T>(T entity)
    {
        // Save logic here
    }

    public void LoadEntity<T>(T entity)
    {
    // Load logic here
    }
}

// Interface defining what the access layer should look like
public interface IDal
{
    void SaveEntity<T>(T entity);
    void LoadEntity<T>(T entity);
}
于 2014-05-26T16:22:35.253 回答