Onion Architecture - 在哪里放置复杂的数据库查询查找

Question

我一直在为设计决策而苦苦挣扎，希望得到一些反馈。

架构总结： ASP.NET MVC WebAPI 解决方案，带有用 KnockoutJS 编写的 SPA 前端和连接到 SQL DB 的实体框架。

问题：我们有两个实体从一个有点复杂的查找表中提取一个值（Rate）。查找表根据 5 个参数过滤到不同的选项，所有 5 个参数值都可以根据每个实体或相关表的属性确定。除了这个查找值之外，两个实体都可以有“速率修饰符”，它可以向这个查找值添加另一个小量。

问题：如果我们希望在使用这两个实体的任何时候都可以使用这个计算出的比率，我们应该把这个查找逻辑放在哪里？

1. 服务层：有服务请求这些实体，请求 来自数据（基础设施）层存储库的实体，然后 对数据层进行单独调用以获取计算结果 率
2. 数据层：在数据层存储库里面获取所有的 实体并在存储库中查找值
3. UI 层：只需将实体发送到 UI 层，然后有 web 检索 5 个参数的费率的服务
4. DB：在 db 中为这些实体创建一个视图，该视图执行所有 为我们在数据库中的速率查找逻辑
5. 其他建议？

我看到所有这些选项的优点和缺点，但我觉得它们都不对。选项 3 感觉它是最干净的，但可能是性能最差的并且是最健谈的。选项 2/4 将类似业务的逻辑放在数据层中似乎很混乱，选项 1 感觉有点过于复杂和低效。

任何见解将不胜感激！谢谢。

Answer 1

1. 如果您关心分离关注点或保持一切整洁，那么最好将其保留在服务层中。正如您所建议的，让 UI 层调用服务层，服务层又调用数据层。服务层是业务逻辑通常所在的地方。这是理想的情况。

2. 但是，如果您关心速度，我认为最好将数据库层中的内容作为存储过程保存。以我的经验，这表现得非常好。但通常最好不要跨层传播业务逻辑。

无论您使用哪种解决方案，最好根据您的优先级进行选择 - 关注点分离或速度等。

请让我们知道您选择了什么。