还原域对象的最佳方法 [英] Optimum Way To Restore Domain Object

查看:98
本文介绍了还原域对象的最佳方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是一个如此简单且常见的情况,我想知道到目前为止如何管理以及为什么现在遇到问题.

This is such a simple and common scenario I wonder how did I managed until now and why I have problems now.

我有这个对象(基础结构程序集的一部分)

I have this object (part of the Infrastructure assembly)

public class Queue {}

public class QueueItem
{
    public QueueItem(int blogId,string name,Type command,object data)
    {
        if (name == null) throw new ArgumentNullException("name");
        if (command == null) throw new ArgumentNullException("command");
        BlogId = blogId;
        CommandType = command;
        ParamValue = data;
        CommandName = name;
        AddedOn = DateTime.UtcNow;
    }


    public Guid Id { get; internal set; }
    public int BlogId { get; private set; }
    public string CommandName { get; set; }
    public Type CommandType { get; private set; }
    public object ParamValue { get; private set; }
    public DateTime AddedOn { get; private set; }
    public DateTime? ExecutedOn { get; private set; }
    public void ExecuteIn(ILifetimeScope ioc)
    {
        throw new NotImplementedException();
    }
}

这将在像这样的另一个程序集中创建

This will be created in another assembly like this

 var qi = new QueueItem(1,"myname",typeof(MyCommand),null);

这里没有什么异常的.但是,此对象将被发送到存储库中.队列对象将询问存储库中的项目.存储库应重新创建QueueItem对象.

Nothing unusal here. However, this object will be sent t oa repository where it will be persisted.The Queue object will ask the repository for items. The repository should re-create QueueItem objects.

但是,如您所见,QueueItem属性是不变的, AddedOn 属性在创建该项时仅应设置一次. Id 属性将由Queue对象设置(这并不重要).

However, as you see, the QueueItem properties are invariable, the AddedOn property should be set only once when the item is created. The Id property will be set by the Queue object (this is not important).

问题是我应该如何在存储库中重新创建QueueItem?我可以有另一个构造函数,该构造函数将要求所有属性的每个值,但我不希望该构造函数可用于最初将创建队列项的程序集.该存储库是不同程序集的一部分,因此内部存储库将无法工作.

The question is how should I recreate the QueueItem in the repository? I can have another constructor which will require every value for ALL the properties, but I don't want that constructor available for the assembly that will create the queue item initially. The repository is part of a different assembly so internal won't work.

我考虑过要提供一种工厂方法 QueueItem类 { /* ..其余的定义.. */

I thought about providing a factory method class QueueItem { /* ..rest of definitions.. */

     public static QueueItem Restore(/* list of params*/){}
   }

这至少可以清除意图,但是我不知道为什么我不喜欢这种方法.我也可以仅通过Queue来强制执行项目创建,但这意味着将Queue作为依赖项传递给仓库,这又不是我想要的.为此要有一个特定的工厂对象,似乎也有些过分.

which at least clears the intent, but I don't know why I don't like this approach. I could also enforce the item creation only by the Queue , but that means to pass the Queue as a dependency to the repo which again isn't something I'd like. To have a specific factory object for this, also seems way overkill.

基本上我的问题是:什么是在存储库中重新创建对象的最佳方法,不将特定的创建功能暴露给另一个使用者对象.

Basically my question is: what is the optimum way to recreate an object in the repository, without exposing that specific creational functionality to another consumer object.

更新

重要的是要注意,通过存储库,我是指模式本身是一种抽象,而不是ORM的包装.域对象的保存方式或位置无关紧要.重要的是如何由存储库重新创建.另一个重要的事情是我的域模型 不同于持久性模型.我确实使用了RDBMS,但是我认为这只是实现细节,不应该具有任何重要性,因为我正在寻找不依赖于特定存储访问权限的方式.

It's important to note that by repository I mean the pattern itself as an abstraction, not a wrapper over an ORM. It doesn't matter how or where the domain objects are persisted. It matters how can be re-created by the repository. Another important thing is that my domain model is different from the persistence model. I do use a RDBMS but I think this is just an implementation detail which should not bear any importance, since I'm looking for way that doesn't depend on a specific storage access.

虽然这是一个特定的场景,但它基本上可以应用于将由存储库恢复的每个对象.

While this is a specific scenario, it can applied to basically every object that will be restored by the repo.

Update2

好吧,我不知道该如何忘记AutoMapper.我的错误印象是它不能映射私有字段/设置者,但可以映射,我认为这是最好的解决方案.

Ok I don't know how I could forget about AutoMapper. I was under the wrong impression it can't map private fields/setter but it can, and I think this is the best solution.

实际上我可以说最优解决方案(IMO)是按顺序排列的:

In fact I can say the optimum solutions (IMO) are in order:

  1. 直接反序列化(如果有).
  2. 自动映射.
  3. 域对象本身的工厂方法.

前两个不需要该对象做任何特别的操作,而第三个不需要该对象提供针对这种情况的功能(一种输入有效状态数据的方法).它有明确的意图,但几乎可以完成映射器工作.

The first two don't require the object to do anyting in particular, while the third requires the object to provide functionality for that case (a way to enter valid state data). It has clear intent but it pretty much does a mapper job.

答案 已更新

要回答自己,在这种情况下,最佳方法是使用工厂方法.最初,我选择了Automapper,但发现自己经常使用工厂方法.自动映射器有时可能有用,但在很多情况下还不够用.

To answer myself, in this case the optimum way is to use a factory method. Initially I opted for the Automapper but I found myself using the factory method more often. Automapper can be useful sometimes but in quite a lot of cases it's not enough.

推荐答案

您谈到了对象本身的工厂方法.但是DDD声明实体应该由工厂创建.因此,您应该拥有一个QueueItemFactory,它可以创建新的QueueItems并还原现有的QueueItems.

You talked about a factory method on the object itself. But DDD states that entities should be created by a factory. So you should have a QueueItemFactory that can create new QueueItems and restore existing QueueItems.

好吧,我不知道该如何忘记AutoMapper.

Ok I don't know how I could forget about AutoMapper.

我希望我能忘记AutoMapper.仅仅看一下丑陋的API就能使我不寒而栗.

I wish I could forget about AutoMapper. Just looking at the hideous API gives me shivers down my spine.

这篇关于还原域对象的最佳方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆