任何人都可以确认将存储库模式与 web 服务集成的最佳方法......实际上我的存储库模式现在在 c# 中工作。我有 3 个项目，DataAccess、Services 和我的表示层。
问题是我的表示层有很多东西......我有一个 ASP.NET MVC 站点，我有一个 WPF 应用程序，我们即将创建另一个站点 + 外部公司也需要访问我们的存储库。
目前我刚刚添加了服务层作为对每个站点的引用...但是通过 Web 服务提供数据访问的正常方式不是吗？(WCF) - 如果是这种情况，这会破坏服务层吗？还是我应该将服务层转换为 Web 服务？
有谁知道这个速度的优点和缺点是什么？
我想我理解你的困境。如果我理解正确，那么您的服务层由纯虚构组成。http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)。
如果我在上面假设正确，那么您的服务层不应该受到 WCF 的引入的影响。WCF 本质上是一个提供互操作性的附加表示层，位于 UI 表示层和任何业务逻辑层之间。因此，您的 WCF 服务将调用您的服务层，该层可以根据需要访问存储库。
WCF 提供了高度的互操作性，所以我认为它是一个很好的选择。不过，如果您打算与不同的编程语言互操作，我会使用 basicHttp 绑定，因为这是最灵活的。不用担心速度。有很多解决方案可以缓解 WCF 导致的任何瓶颈。
祝你好运，如果我能以其他方式提供帮助，请告诉我。
也许 web 服务不是最好的方法，如果我可以完全访问服务程序集，那么我认为程序集与我的应用程序共享服务层总是更好。
我的应用程序做类似的事情，但它们都需要访问服务层 - 以及业务逻辑并获取信息......
在这种情况下——它总是最好使用与服务层的程序集共享，而不是使用 HTTP 协议或在 wcf 上使用 TCP 提供 WCF Web 服务——例如？
再次感谢
首先，并非所有调用者都必须使用相同的存储库 API；对于外部公司尤其如此。
WCF 是基于接口的。这意味着如果您需要重用一些逻辑代码，可以使用 IoC/DI 来注入 WCF 而不是 DAL（但使用相同的接口）——通过使用程序集共享。听起来这就是你正在做的事情。这在许多情况下都有效，但不是全部；从根本上讲，基于 Web 服务的 API 通常需要进行不同的设计才能达到最佳效果。从 SOA 的角度来看，它也不是 100% 纯的，但它可以完成工作，并允许更智能的域实体，因此在 Intranet（等）场景中（IMO）是完全合理的。
外部调用者通常只使用基于 wsdl/mex 的 API（而不是程序集共享），但一切皆有可能......
是否与您的客户端应用程序共享您的服务/API 程序集是相当主观的。如果您是一家完整的 Microsoft 商店，并且在整个应用程序堆栈中使用 .NET，那么我会说共享 API 是获得代码重用的好方法（您必须小心设计 API 以免流血域问题，例如存储库，到您的演示文稿中。）如果您没有任何计划将您的客户端应用程序迁移到其他平台（即您计划在可预见的未来继续使用 .NET），那么我认为分享它是完全可以接受的您的服务/API 程序集（即便如此，在多平台客户端环境中，与 .NET 客户端共享服务/API 仍然应该是可以接受的。）“架构理想”和“实用且可实现”之间总是存在权衡在预算之内'。您可以花费大量时间、金钱和精力来尝试实现架构上的理想，而实际上与实际之间的差距通常并没有那么大。选择不共享 API 并从本质上重新创建它以维护“正确”的 SOA，只使用合同，实际上会增加工作量并引入维护麻烦，这在特定时间对于您的特定项目很可能不值得。鉴于您通常已经是“面向服务的”，如果在未来某个时间点您需要客户端上的仅合同消费可以提供的好处，那么您已经准备好去那里了。但不要过早地推得太远。选择不共享 API 并从本质上重新创建它以维护“正确”的 SOA，只使用合同，实际上会增加工作量并引入维护麻烦，这在特定时间对于您的特定项目很可能不值得。鉴于您通常已经是“面向服务的”，如果在未来某个时间点您需要客户端上的仅合同消费可以提供的好处，那么您已经准备好去那里了。但不要过早地推得太远。选择不共享 API 并从本质上重新创建它以维护“正确”的 SOA，只使用合同，实际上会增加工作量并引入维护麻烦，这在特定时间对于您的特定项目很可能不值得。鉴于您通常已经是“面向服务的”，如果在未来某个时间点您需要客户端上的仅合同消费可以提供的好处，那么您已经准备好去那里了。但不要过早地推得太远。如果在未来的某个时间点，您需要客户端上的仅合同消费可以提供的好处，那么您已经准备好去那里了。但不要过早地推得太远。如果在未来的某个时间点，您需要客户端上的仅合同消费可以提供的好处，那么您已经准备好去那里了。但不要过早地推得太远。
鉴于您的需求，从到目前为止我从这些帖子中收集到的信息来看，我认为您的服务也走在了正确的轨道上。存储库（a la Evans，DDD）绝对是一个领域问题，因此，从表示层的角度来看，您真的不必担心它。您的服务是您的域的网关，它是您的业务逻辑的所在地。存储库只是一种支持工具，可以帮助您实现与数据存储的域隔离（它们确实是美化的集合，坦率地说......它们在动态和复杂的域中可能有点痛苦。简单的数据映射器， （Fowler，PofEAA）从长远来看通常更容易处理且不那么复杂，并且允许围绕数据检索逻辑的更具适应性的行为集中在域服务中。) 除了大量使用对 REST 服务的 AJAX 调用之外，如果您在域周围公开了足够的服务/API，那是您的客户唯一应该担心的事情。将所有其余的业务逻辑完全封装在您的域范围内，并使您的客户尽可能轻量级，并从“存储库”或“数据映射器”等概念中抽象出来。
以我的经验，唯一需要跨客户端到域边界共享的非服务或 API 概念是上下文……而众所周知，在面向服务的应用程序中跨越该边界可能非常困难。