我正在构建一个服务，该服务根据收到的请求类型执行一组已配置的活动。每个活动都涉及到数据库并检索/更新某种信息。每个活动的逻辑可以被推广并在不同的请求类型中重用。活动可能需要在服务请求期间参与交易。
一个选项，我正在考虑让每个活动都保持自己对DAL /数据库的访问权限。这将活动完全封装到一个独立的可重用部分中，但是对于一个请求多次访问数据库似乎不是一个可行的选择。我真的不知道如何在这里的多个活动中轻松实现交易的概念。
第二个选项是将所有活动封装到一个大活动中，然后点击数据库一次。但是这不允许针对不同的请求重用和配置这些活动。
有没有人有任何关于什么应该是解决问题的最佳方法的建议和意见？谢谢你的帮助。
答案 0 :(得分：1)
我担心没有细节选择设计有点困难。我的第一选择是遵循第一种选择;这听起来像一个更简单的方法。第二个听起来会表现得更好，但是在我的脑后有一个声音在低声说出过早的优化和邪恶。
这实际上取决于此服务的使用量。是否会受到很大的负担？服务器是在运行一些功能的强大机器上运行的，还是在运行多个服务的其他几个VM上运行？
如果你想保持安全，我会建议原型。只需构建一个使用数据库的小程序，就像应用程序在您描述的第一个场景中使用它一样，让它运行。没什么好看的，只是让它随机抽取数据进出数据库。不要忘记在那里存储大量数据以查看它是如何应对的。如果它似乎没有你的第一个选择。如果没有，你可以转向更精细的东西。
在侧面说明中了解您选择的数据库。你不是第一个试图给它施加重负荷的人;大多数数据库都提供了应对此类事情的机制。
答案 1 :(得分：0)
您可能需要考虑NServiceBus。您可以将多个消息处理程序组合在一起，为您提供所需的管道。它还在一个事务中运行所有处理程序，满足您的事务需求。由于每个管道都是自治的，因此您可以全天扩展。唯一需要注意的是，如果要维护该模型，则必须执行相关的请求/响应（NSB也支持此模型）。
答案 2 :(得分：0)
从业务逻辑中抽象出数据访问实现，因此您不依赖于它;如果你在.Net中，你通常会使用一个界面。
执行此操作时，您需要设计界面 - 根据工作的逻辑分区进行设计：思考ISP，SRP，CRP和CCP
定义了界面后，您可以根据需要随意构建任意数量的实现，并且可以随时将它们交换出来;也没有理由不能同时使用两者 - 并且有一些cotrols执行的逻辑，以便在适当的时候调用uber，或者在其他时间调用另一个实现。
答案 3 :(得分：0)
决定可能取决于交易要求。如果所有活动都需要查看数据库的相同快照，则它们不再是真正独立的。所以这些活动并非完全独立。
两种情况下对数据库的请求数是多少？即一个典型的权力 - 用户将拥有多少活动，系统上有多少用户等等。此外，通过更少的请求通常会有更多数据 - 在组合请求时看起来如何？
每分钟的点击次数从5增加到10不是问题。 1000个用户增加5倍。
您可以批量处理这些请求吗？您可以在活动和DAL之间创建接口，以便批量处理请求。例如。所有活动都发布其请求并接收结果，请求使用一组活动来处理。一个简单的request实现仍然可以运行单个请求。