具有 2 个服务的存储库模式 2 个数据访问层 - C# DDD？
谁能帮忙，我有两个应用程序，它们几乎相同。 它们有完全不同的表示层（Web），业务逻辑和数据库几乎相同。 基本上，一个应用程序有一些其他应用程序没有的功能。
所以我想知道我是否可以在不违反任何规则等的情况下执行以下操作
每个应用程序都有自己的表示层。
每个应用程序都有自己的服务层。
每个应用程序都有自己的数据访问层。
每个应用程序共享另一个服务层。
因此，两个应用程序都可以访问共享服务层，因为业务逻辑是相同的，但它们都有另一个服务层，其中有 5 或 6 个特定于该实际应用程序的方法。
数据访问层 - 我无论如何也看不到共享这个，因为有 2 个不同的数据库与实体框架，因此它在那里有 EDM，所以它不是动态的 - 并且表略有不同。
我可以在共享数据访问层上使用 IOC，我想
有人会帮忙或评论一下这是一个很好的做法吗？我不想做的是，当很多服务是共享的时，只有一个单独的服务层。
是这样吗？一个好主意？ 也许我理解错了，有更好的方法吗？
Can anyone help, I have 2 applications and they are nearly identical. they have a completely different presentation layer (web) and the business logic and database are nearly identical. Basically one app has some things that the other doesn't.
so i was wondering if i can do the following without breaking any rules etc
Each app has their own presentation layer.
Each app has their own service layer.
Each app has their own data access layer.
Each app shares another service layer.
Hence the shared service layer both apps can access as the business logic is identical, but they both have another service layer which has 5 or 6 methods in there which are specific to that actual app
The data access layer - I don't see anyway of sharing this as there are 2 different db's with entity framework hence its got the EDM in there so its not dynamic - and the tables differ slightly.
I could use IOC on the shared data access layer I suppose
Would anyone help or comment weather this is good practise.. What I didn't want to do is have only a separate service layer when a lot of it is shared..
Is this a good idea? Maybe i have got it wrong, is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如 Arjen de Blok 所说，您的业务实体应该使用存储库，存储库是一个具有查询、更新或插入域实体方法的对象。
描述存储库的接口属于域层，但实现属于基础设施层 (DAL)。
您可以在两个项目之间共享域和基础设施库。 如果这两个项目应该通过共享 Web 服务或共享数据库检索数据，您只需选择（即注入）存储库的正确实现（您的域对象仅了解存储库的接口，而不了解具体的存储库）类型）
As Arjen de Blok said, your business entities should use a repository, a repository is an object with methods to query, update or insert domain entities.
The interface which describes your repository belongs to your domain layer, but the implementation belongs to the infrastructure layer (DAL).
You can share the domain and infrastructure libraries between your two projects. If these two projects should retrieves their data through a shared web service or a shared database, you just have to choose (i.e inject) the correct implementation of your repository (your domain objects know only about the interface of your repository, not about the concrete type)
如果业务逻辑基本相同，那么您应该首先关注这一点。
如果您想做 DDD，那么您应该首先识别您的实体和（业务）服务，并将它们放在一个库中。
这些实体和业务服务应该与您的基础设施层（您的 DAL）通信。
如果这两个应用程序中的基础设施层非常不同，则尝试使用接口。 因此，用接口包装基础设施层，并且仅通过这些接口从领域层与基础设施层进行通信。
要将业务逻辑绑定到基础设施的实现，您可以使用 IoC/DI。
If the business logic is mostly identical then you should focus to this first.
If you want to do DDD then you should identify your entities and (business) services first and place these in a single library.
These entities and business services should talk to your infrastructure layer (your DAL).
If the infrastructure layer is very different in these two applications then try to work with interfaces. So wrap the intfrastructure layer with interfaces and only talk from the domain layer to your infrastructure layer via these interfaces.
To bind your business logic to your infrastructure's implementation you could use IoC/DI.
您可以将 DAL 与存储库接口统一起来。 然后，您可以跨项目实现该接口。 您最终可能还会得到一个 EF Repository 基类。 您可以将类似的技术应用于服务，利用通用接口，然后专门化服务实现。
You could unify the DAL with a Repository interface. You could then implement the interface across projects. You will probably end up with a EF Repository base class as well. You could apply a similar technique to the services, leverage a common interface and then specialize the service implementations.