我的服务和存储层的职责

发布于 2024-10-21 06:51:28 字数 1449 浏览 1 评论 0原文

有一天我问了这个问题：

答案（好吧，只有一个人，但我已经有预感这不是一个好主意）是不，存储库稍后不应该处理DTO 对象（它们的目的纯粹是通过线路发送），服务层应该处理它。

现在我已经提出了一个结构，需要你的意见。这个想法是，当这样做有意义时，存储库层可以返回我定义的名为 IProjectable 的接口类型。这包装了查询（存储库层尚未执行查询），但不允许使用者更改查询（它不是 IQueryable），只是对其执行投影操作（到目前为止对我来说）只有 First 和 ToPagedList）将执行投影并实际执行查询。

所以在存储库中是这样的：

public IProjectable<User> GetUser(int id)
{
  var query = from u in Set<User>()
              where u.UserID == id
              select u;

  return query.AsProjectable();
}

在服务层中是这样的：

var dto = repository.GetUser(16).Single(u => new SimpleUserDto
{
  FullName = u.FirstName + " " + u.LastName,
  DisplayAddress = u.Address.Street + u.Address.HouseNumber,
  OrderCount = u.Orders.Count()
});

return dto;

我是否正确地说，在这里进行实际的数据访问仍然是存储库层的责任（应该如此），并且投影到可序列化的层form 是服务层的责任（理应如此）？

我认为有效地执行此操作的唯一其他方法（从存储库返回 User 并对其 Orders 执行 Count()服务层中的 会导致对数据库的额外查询）是定义一个具有所有这些属性的类型并从存储库层返回它，只是不要将其称为“Dto”，这看起来很愚蠢它与 DTO 相同，只是为了“纯粹”而没有命名相同。这样一来，我似乎就可以鱼与熊掌兼得了。

我看到的缺点是，在服务层执行实际上无法转换为 SQL 的投影（它不应该）不必担心的情况下，或者在执行如此复杂的投影的情况下，您可能会遇到不匹配的情况这使得人们怀疑哪一层正在执行实际的数据访问。

顺便说一句，如果重要的话，我正在使用 Entity Framework 4。

原文

The other day I asked this question:

Should the repository layer return data-transfer-objects (DTO)?

The answer (well by just one person, but I already had a hunch that it wasn't a good idea) was that no, the repository later should not have to deal with the DTO objects (their purpose is purely to be sent over the wire) and the service layer should deal with that.

Now I've come up with a construction in the meantime that I need your opinion on. The idea is that, when it makes sense to do so, the repository layer can return an interface type I've defined called IProjectable. This wraps the query (the repository layer does not execute the query yet) but does not allow the consumer to change the query (it's not IQueryable), just to perform projection operations on it (so far for me only First and ToPagedList) that would perform the projection and actually execute the query.

So something like this in the repository:

public IProjectable<User> GetUser(int id)
{
  var query = from u in Set<User>()
              where u.UserID == id
              select u;

  return query.AsProjectable();
}

And in the service layer something like this:

var dto = repository.GetUser(16).Single(u => new SimpleUserDto
{
  FullName = u.FirstName + " " + u.LastName,
  DisplayAddress = u.Address.Street + u.Address.HouseNumber,
  OrderCount = u.Orders.Count()
});

return dto;

Am I correct in saying that doing the actual data access here is still the responsibility of the repository layer (as it should be) and that the projection to a serializable form is the responsibility of the service layer (as it should be)?

The only other way I see to do this efficiently (returning a User from the repository and doing the Count() on his Orders in the service layer would result in an extra query to the database) is to define a type that has all these properties and return it from the repository layer and just don't call it "Dto", which seems silly as it would be identical to the DTO just not named the same for the sake of "purity". This way, it seems, I can have my cake and eat it for the most part too.

The downside I see is that you can get a mismatch where the service layer performs projections that can't actually be translated to SQL which it shouldn't have to worry about, or where it performs such complex projections that makes it questionable what layer is doing the actual data access.

I'm using Entity Framework 4 by the way, if it matters.

分享到QQ

分享到微博