在.net中实现请求-回复模式答案

【问题标题】：implementing request-reply pattern in .net在.net中实现请求-回复模式
【发布时间】：2011-09-09 21:00:17
【问题描述】：

只是想知道我是否朝着正确的方向前进。

我正在实现请求-答复（请求-响应）模式，其中每个操作都发送一个请求对象并返回响应对象。

例如：

Public FetchCustomerResponse Fetch(FetchCustomerRequest searchObject)

我对实现我的存储库有点困惑。我有一个像这样的通用存储库接口：

public interface IRepositoryReadOnly<TGetRequest, TGetResponse> : IDisposable
{
    TGetResponse FetchAll();
    TGetResponse Fetch(TGetRequest reqObject);
}

public interface IRepositoryReadWrite<TGetRequest, TGetResponse, TPutRequest, TPutResponse> : IRepositoryReadOnly<TGetRequest, TGetResponse>
{
    TPutResponse Insert(TPutRequest dto);
    TPutResponse Update(TPutRequest dto);
    void Delete(long id);
}

我遇到的问题是void Delete(long id);。

我希望我的删除方法接受一个包含其他字段的对象，例如 UserName, TimeStamp 等。

我应该使用属性创建一个 DeleteRequestObject 并将其添加到 IRepositoryReadWrite 吗？

如果我这样做，它会是这样的。

public interface IRepositoryReadWrite<TGetRequest, TGetResponse, TPutRequest, TPutResponse, TDeleteRequest, TDeleteResponse> : IRepositoryReadOnly<TGetRequest, TGetResponse>
{
    TPutResponse Insert(TPutRequest dto);
    TPutResponse Update(TPutRequest dto);
    TDeleteResponse Delete(long TDeleteRequest);
}

由于所有操作的 DeleteRequest 和 DeleteReponse 对象都是相同的（我认为是这样），这是一个很好的实现，还是我完全偏离轨道并且做错了？

【问题讨论】：

TDeleteResponse Delete(TDeleteRequest request);，你的意思是在最后一个代码示例的最后一行，对吧？
请求-响应模式只在松散耦合的系统中真正产生，其中通信协议并不严格。当对象相互通信时，它们之间可以有更明确的契约，由编译器强制执行。在这种情况下，请求-响应模式会在代码中引入不必要的噪音。你可以考虑是否真的有必要。
在域驱动的设计存储库中提供对实体或聚合根的访问。我认为请求/响应模式并不适合存储库。请求/响应模式通常用于应用程序的服务层。某种汇编类或辅助方法正在请求/响应对象和域对象之间进行转换。

标签： c# design-patterns architecture

【解决方案1】：

我会说你可以这样，额外的 Request-Response 对象绝对不会伤害你。

例如，如果您在某个阶段发现您不断地通过 id 删除一些条目，并且为此您经常需要创建一个填充了一个属性的完整请求对象，您始终可以创建一个扩展方法 -甚至是原生类方法，如果你愿意的话 - 这将接受 long id 并为你构造请求对象。

如果你只保留 id，那么在某些阶段你可能需要请求对象，但修改会困难得多。

【讨论】：