洋葱架构 - 在何处放置复杂的数据库查询查找

Question

我一直在努力做出设计决定，并希望得到一些反馈。

架构摘要： 带有在KnockoutJS和Entity Framework中编写的SPA前端的ASP.NET MVC WebAPI解决方案连接到SQL DB。

问题：我们有两个实体从一个有点复杂的查找表中提取值（Rate）。查找表基于5个参数过滤到不同的选项，可以基于每个实体或相关表上的属性确定所有5个参数值。在此查找值之上，两个实体都可以使用“速率修改器”，这可以为此查找值添加另一个小量。

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

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

我看到所有这些选项的优点和缺点，他们都没有对我这么好。选项3感觉它是最干净的，但可能是性能最差的，也是最健谈的。选项2/4看似凌乱，在数据层中放置类似业务的逻辑，选项1感觉有点过于复杂和低效。

非常感谢任何见解！谢谢。

Answer 1

1. 如果您担心分离问题或保持一切清洁，那么最好将其保留在服务层中。正如您所建议的那样，让UI层调用服务层，而服务层又调用数据层。服务层是业务逻辑通常所在的位置。这是理想的情况。

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

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

请告诉我们你的用途。