将服务添加到ASP.NET控制器范围
简短：如何/如何将服务添加到整个组件的所有（ODATA）控制器的范围，而无需将它们添加到应用程序中的每个控制器（即给大会带有其自身服务的永久范围）？
上下文：
我目前正在研究带有以下架构的基于ODATA DDD/ACTOR的ASP.NET WebService：
措辞：
- 本地域 - 拥有给定实体域的
- 域- 想要访问给定实体的域（仅读取）
每个域都有其自己的dbcontext，以防止对外国表的写入访问，但仍然能够读取它们并减少耦合。 DBContext仍在范围内。
如果要访问外国域的数据，则为DB-Context添加一个只读模型，并提供一个仅读取的存储库，该存储库由该外国域实现并在外国域中提供（确保两个存储库都使用相同dbContext）
这意味着您必须多次提供相同的服务，以使用不同的CTOR参数和实例（一个用于访问存储库的每个外国域），
我提出了两个主要解决方案：
- 每个服务提供其本机中的实现和接口域和界面在外国域中扩展。接口新接口是内部（我想避免的）
- 外国域具有自己的永久注入范围，它允许其仅提供本机接口而无需任何其他代码。这导致后
一个解决方案上方所述的问题具有多个不变性，例如在每个命令的开始时创建扩展范围，但是我认为所陈述的变体将是最干净的解决方案。
Short: How/is it possible to add services to the scope of all (Odata)Controllers of a assembly without adding them to every controller in the application (i.e. give the assembly a permanent scope with its own services)?
Context:
I am currently working on an Odata DDD/Actor based Asp.Net Webservice with the following architecture:
Wording:
- Native Domain - The domain which owns the given entity
- Foreign Domain - The domain which want to access the given entity (read only)
Each domain has it's own DbContext to prevent write access to foreign tables but to be still able to read them and to reduce coupling. The DbContext is still scoped.
if you want to access data of foreign domains, you add a read-only model to your db-context and provide a read-only repository, implemented by that foreign domain and provided in the foreign domain (to make sure both repositories use the same dbContext)
this means that you have to provide the same service multiple times with different ctor-parameters and instances (one for each foreign domain which accesses the repository)
I came up with two major solutions:
- each services provides the implementation and interface in its native domain and the interface is extended in the foreign domain. The interface new interface is internal (I would like to avoid this)
- the foreign domain has its own, permanent injection scope which allows it to just provide the native interface without any additional code. this leads to the problem stated above
the latter solution has multiple invariants like creating the extended scope at the start of each command, but I think the stated variant would be the most clean solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论