在我的解决方案中，我有一个 Web 应用程序项目和一个包含所有业务逻辑的类库项目，并且当我使用实体框架时，它也充当数据访问层。这意味着我的 edmx 在这一层本身。
我在这个类库项目中有大约 34 个类，每个类中平均有 6 个公共方法。到目前为止，这些类都是直接从 Web 应用程序调用的。没问题。现在我想介绍一下 UI 和业务逻辑层之间的 WCF 层。
这意味着我必须为我的所有方法编写包装器方法并将它们公开在 WCF 服务中。这是否意味着 34 * 6 = 204 个方法（大约）将作为操作合同出现在我的服务层中？根据OO，我认为这是一个太大的类，所以感觉不对。
我知道有通用服务设计模式，但我还缺少什么吗？请指教。
【问题讨论】：
标签： wcf
您可以尝试 RIA 服务
http://www.silverlight.net/getstarted/riaservices/
我用的是这个。
2.1。将 SVC 服务指向您的实现，例如：
<%@ ServiceHost Language="C#" Debug="true" Service="BusinessLayer.Service" %>
BusinessLayer.Service 是您的 Class 项目中的一个类。 （需要在服务中引用）
2.2。将服务行为指向合约：
<service behaviorConfiguration="ServiceBehavior" name="BusinessLayer.Service">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpBinding" contract="BusinessLayer.IService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
编辑名称（BusinessLayer.Service）和合同（Businesslayer.IService）
创建合约接口 BusinessLayer.IService（在您的 Class 项目中）：
命名空间业务层 { [服务合同] 公共接口 IService { [运营合同] 无效 DoWork(); } }
修改使用接口的现有实现（这是您现有的代码）：
命名空间业务层 { 公共类服务：IService { 公共无效 DoWork() { } } }
【讨论】：
为什么要将整个业务逻辑层包装在一个 WCF 层中？在采用这种新方法之前，我会非常仔细地研究您这样做的原因。您是否有物理原因无法解决，例如访问数据库的业务逻辑需要位于 DMZ 之外？如果是这样，好的。但如果不是，我会三思而后行地采用这种方法。
话虽如此，如果您别无选择，我会避免使用封装 UI 所需的每个公共方法的整体 WCF 类。首先，我将在 Web 应用程序端引入一个接口，以便您可以依赖 UI 中的抽象而不是具体的实现。此外，我会考虑使用 WCF REST 服务。您可以使用 ServiceRoute 来避免引入任何 *.svc 文件。然后，您可以使用 WebGet/WebInvoke 属性装饰要公开的方法。这可能会节省大量编码。
【讨论】：
嗯，
我们有一个类似的应用程序，但课程的数量甚至更多。您在这里担心的是您不愿意为业务逻辑服务器的核心类提供序列化（这是通过 WCF 传递对象所需要的）。
假设您有一个经典的三层应用程序，其中业务逻辑服务器和客户端访问同一个数据库。您需要做的只是 1) 确保所有对象都具有唯一标识（这可能是字符串或 Guid）和 2) 在所有 WCF 调用中传递对象 ID。这意味着您不要在 WCF 端公开任何类。
这可能会更安全，因为您有一个 Web 应用程序。
【讨论】：
这是错误的。您的服务不应超过 20 个操作。如果您需要完全相同的操作，您应该为每个业务类创建合同和服务包装器。这通常会导致繁琐的界面，这对于分布式场景来说不是很好的解决方案。在这种情况下，您应该将服务层建模为将多个调用组合为一个的外观。
【讨论】：