C# 和 WCF 中具有存储库模式的 Web 服务？
任何人都可以确认将存储库模式与 Web 服务集成的最佳方法吗...实际上我的存储库模式现在在 C# 中工作。 我有 3 个项目：DataAccess、Services 和我的表示层。
问题是我的表示层有很多东西...我有一个 ASP.NET MVC 站点，我有一个 WPF 应用程序，我们即将创建另一个站点 + 外部公司也需要访问我们的存储库。
目前我刚刚添加了服务层作为每个站点的参考...但这不是通过 Web 服务提供数据访问的正常方法吗？ (WCF) - 如果是这种情况，这会破坏服务层吗？ 或者我应该将服务层转换为网络服务？
有人知道这个的优点和缺点是什么，速度吗？
Can anyone confirm the best way to integrate the repository pattern with webservices.... Well actually i have my repository patter working now in c#. I have 3 projects, DataAccess, Services and my presentation layer.
Problem is my presentation layer is a number of things... I have a ASP.NET MVC site, I have an WPF application and we are about to create another site + an external company needs access to our repository also.
Currently i have just added the services layer as reference to each of the sites... But is not the normal way to provide data access via web services? (WCF) - if this is the case will this break the services layer? or should i convert the services layer to a web service?
Anybody know what the PROS and CONS are of this, speed??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想我理解你的困境。 如果我理解正确的话，那么您的服务层由纯粹的制造组成。 http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)。
如果我上面的假设正确，那么您的服务层根本不会受到 WCF 引入的影响。 WCF 本质上是一个附加的表示层，位于 UI 表示层和任何业务逻辑层之间，提供互操作性。 因此，您的 WCF 服务将调用您的服务层，该服务层可以根据需要访问存储库。
WCF 提供了高度的互操作性，因此我认为它是一个很好的选择。 不过，如果您打算与不同的编程语言进行互操作，我会使用 basicHttp 绑定，因为这是最灵活的。 不用担心速度。 有很多解决方案可以缓解 WCF 造成的任何瓶颈。
祝你好运，如果我能以其他方式提供帮助，请告诉我。
I think I understand your dilemma. If I understand correctly then your services layer consists of pure fabrications. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design).
If I assume correctly above, then your services layer should not be impacted at all by the introduction of WCF. WCF is essentially an additional presentation layer that provides interoperability, sitting between your UI presentation layer and any business logic layers. So your WCF services would then call your services layer, which may access repositories as needed.
WCF provides a high degree of interoperability so I think it is an excellent choice. I would use basicHttp bindings though, if you intend to interop with different programming languages as this is the most flexible. Don't worry about the speed. There are plenty of solutions out there to mitigate any bottlenecks that result due to WCF.
Good luck, and let me know if I can help in any other way.
首先，并非所有调用者都必须使用相同的存储库 API； 对于外部公司来说尤其如此。
WCF 是基于接口的。 这意味着如果您需要重用某些逻辑代码，则可以使用 IoC/DI 来注入 WCF 而不是 DAL（但使用相同的接口） - 通过使用程序集共享。 听起来这就是你正在做的事情。 这在很多情况下都有效，但不是全部； 从根本上来说，基于 Web 服务的 API 通常需要进行不同的设计才能达到最佳效果。 从 SOA 的角度来看，它也不是 100% 纯粹的，但它可以完成工作，并允许更智能的域实体，因此在 Intranet（等）场景中它（IMO）是完全合理的。
外部调用者通常只使用基于 wsdl/mex 的 API（而不是程序集共享），但一切皆有可能......
Well first - not all callers have to use the same repository API; this is especially true of an external company.
WCF is interface based. This means that if you need to re-use some logic code, it is possible to use IoC/DI to inject WCF rather than a DAL (but using the same interface) - by using assembly sharing. It sounds like this is what you are doing. This works in many cases, but not all; fundamentally web-service based APIs often need to be designed differently in order to be optimal. It also isn't 100% pure from an SOA viewpoint, but it gets the job done, and allows more intelligent domain entities, so in an intranet (etc) scenario it is (IMO) perfectly reasonable.
An external caller would typically just use the wsdl/mex-based APIs (rather than assembly sharing), but anything is possible...
也许 Web 服务不是最好的方法，如果我可以完全访问服务组件，那么我认为组件与我的应用程序共享服务层总是更好。
我的应用程序执行类似的操作，但它们都需要访问服务层 - 以及业务逻辑并获取信息...
在这种情况下 - 最好使用与服务层共享程序集，而不是使用以下方式提供 WCF Web 服务例如，HTTP 协议或在 wcf 上使用 TCP？
再次感谢
Maybe webservices are not the best way, if i have full access to the service assembly then i suppose it always better to assembly share the services layer with my applications.
My applications do similar things, but they all need to access the service layer - well the business logic and get back information...
In this case - its always preferable to use assembly sharing with the service layer rather than provide a WCF Web service using HTTP protocol or using TCP on wcf - for example?
Thanks again
是否与客户端应用程序共享您的服务/API 程序集是相当主观的。 如果您是一家完整的 Microsoft 商店，并在整个应用程序堆栈中使用 .NET，那么我会说共享 API 是获得代码重用的好方法（您必须小心如何设计 API，以免流血）如果您没有任何计划将客户端应用程序迁移到其他平台（即您计划在可预见的未来保留在 .NET 上），那么我认为共享是完全可以接受的您的服务/API 程序集（即使如此，在多平台客户端环境中，与 .NET 客户端共享服务/API 仍然应该是可以接受的。）“架构理想”与“实用且可实现”之间始终存在权衡在预算之内'。 您可能会花费大量的时间、金钱和精力来尝试实现架构上的理想，而实际上与实际之间的差距通常并不是那么大。 选择不共享 API 并本质上重新创建它来维护“正确的”SOA（仅使用合同）实际上会增加工作量并带来维护麻烦，而对于此时的特定项目来说，这些麻烦很可能是不值得的。 考虑到您已经普遍“以服务为导向”，如果在未来某个时间点您需要客户端的仅合同消费可以提供的好处，那么您已经准备好去那里了。 但不要太快太推进。
考虑到您的需求，从迄今为止我从这些帖子中收集到的信息来看，我认为您的服务也走在正确的轨道上。 存储库（a la Evans，DDD）绝对是一个领域问题，因此，您实际上不必从表示层的角度担心它。 您的服务是通往您的域的门户，您的域是您的业务逻辑的所在地。 存储库只是一个支持工具，可以帮助您实现与数据存储的域隔离（它们确实是美化的集合，而且坦率地说......它们在动态和复杂的域中可能有点痛苦。简单的数据映射器， （Fowler、PofEAA）从长远来看通常更容易处理且不太复杂，并且允许将围绕数据检索逻辑的更具适应性的行为集中在域服务中。）除了大量使用对 REST 服务的 AJAX 调用之外，如果您在您的域周围公开了足够的服务/API，那么这是您的客户唯一应该担心的事情。 将所有其余的业务逻辑完全包装在您的域范围内，并使您的客户端尽可能轻量，并从“存储库”或“数据映射器”等概念中抽象出来。
根据我的经验，需要跨客户端到域边界共享的唯一非服务或 API 概念是上下文……并且在面向服务的应用程序中跨越该边界可能非常困难。
Whether to share your Service/API assemblies with your client applications is fairly subjective. If you are a full Microsoft shop, and use .NET for your entire application stack, then I would say sharing the API is a great way to gain code reuse (you have to be careful how you design your API so you don't bleed domain concerns, like repositories, into your presentation.) If you don't have any plans to migrate your client applications to other platforms (i.e. you plan to stay on .NET for the foreseeable future), then I think its perfectly acceptable to share your Service/API assemblies (and even then, in a multi-platform client environment, sharing Service/API with .NET clients should still be acceptable.) There is always a trade off between the 'architecturally ideal' and the 'practical and achievable within budget'. You can spend a LOT of time, money, and effort trying to achieve the architecturally ideal, when the gap between that and the practical often isn't really that much. The choice NOT to share the API and essentially recreate it to maintain "correct" SOA, consuming only the contract, can actually increase work and introduce maintenance hassles that quite possibly are not worth it for your particular project at this particular time. Given that you are already generally 'service-oriented', if at a future point in time you need the benefit that contract-only consumption on the client can offer, then your already set to go there. But don't push too far too soon.
Given your needs, from what I have been able to glean from these posts so far, I think your on the right track from your services down too. A repository (a la Evans, DDD) is definitely a domain concern, and as such, you really shouldn't have to worry about it from the perspective of your presentation layer. You services are the gateway to your domain, which is the home of your business logic. Repositories are just a support facility that helps you achieve domain isolation from a data store (they are glorified collections really, and to be quite frank...they can be a bit of a pain in a dynamic and complex domain. Simple data mappers, (Fowler, PofEAA) are often a lot easier to deal with and less complex in the long run, and allow more adaptable behavior around your data retrieval logic to be centralized in your domain services.) Aside from heavy use of AJAX calls to REST Services, if you expose adequate Services/API around your domain, that is the only thing that your clients should have worry about. Wrap up all the rest of your business logic entirely within the confines of your domain, and keep your clients as light weight as possible and abstracted from concepts like 'Repository' or 'Data Mapper' and whatnot.
In my experience, the only non-service or API concept that needs to be shared across the Client-to-Domain boundary is Context...and it can be notoriously difficult to cross that boundary in a service-oriented application.