我正在尝试将六边形体系结构应用于一个项目，该项目将有多个应用程序必须处理相同的域模型。
我们将有一个mvc网站请求应用程序服务，然后处理域模型和数据访问层。到目前为止，一切都很好。
我遇到的问题是应该何时实例化应用程序服务类。我是否应该只为所有用户（单身）提供任何类的一个实例？ 或者我应该为每个用户实例化一个，然后让它保存一些用户数据并存储在用户会话中？ 或者我应该为每个请求实例化一个新类？
当然，任何这些选项都是可行的，但我希望得到您的最佳实践建议。
我认为类越无状态越好，但是无状态类意味着我需要在每个方法调用中传递用户特定的数据，这是我不喜欢的。
答案 0 :(得分：1)
我通常将我的服务和持久性类保留在请求范围内。这有助于确保在出现问题时我可以恢复数据事务并且我没有留下部分数据。
至于为什么你不想要更持久的事务范围，它通常是一种改善性能的非常差的方法，并且可能导致意外的行为。特别是当涉及依赖于瞬态或范围类的单身人士时。因为单例创建一次，所以它的依赖关系被创建一次。对于非线程安全的类，这是非常危险的。 More on scopes here.
至于你对传递用户数据的担忧。我会把你关心的所有信息都放在某种用户数据帮助界面之后。使您的服务依赖于此而不是传递该数据。然后您可以创建特定于您要支持的客户端的用户数据助手。您可以使用依赖注入来配置mvc应用程序以使用该用户数据助手的mvc特定实现。您架构中的其他客户端也可以做同样的事情。
我会为用户信息助手编写一个自定义界面，以确切了解您现有服务的需求。自定义实现可以基于会话数据或客户端可以提供的任何内容。也就是说，实现可能依赖于现有库，但会将此数据转换为您要使用的服务层的通用格式。通过这种方式，您可以在帮助程序中更换用户信息的位置，而不会破坏应用程序的其余部分。