Question

在我的解决方案中，我有一个Web应用程序项目和一个包含所有业务逻辑的类库项目，这也是我使用实体框架时的数据访问层。这意味着我在这一层中拥有自己的edmx。

我在这个类库项目中有大约34个类，每个类中平均有6个公共方法。直到现在，这些类才直接从Web应用程序调用。没问题。现在我想介绍UI和业务逻辑层之间的WCF层。

这意味着我必须为我的所有方法编写包装器方法，并在WCF服务中公开它们。这是否意味着34 * 6 = 204方法（大约）将作为操作合同出现在我的服务层中？根据OO，我认为这个类太大了，所以感觉不对。

我知道有通用服务设计模式，但还有什么我想念的吗？请指教。

Answer 1

好吧，

我们有类似的应用程序但类的数量更高。您担心的是，您不愿意提供序列化（这是将WCF传递对象所需的序列化）到业务逻辑服务器的核心类。

如果您有一个经典的三层应用程序，其中业务逻辑服务器和客户端访问同一个数据库。您需要做的只是1）确保所有对象都具有唯一标识（可以是字符串或Guid）和2）在所有WCF调用中传递对象ID。这意味着你不要在WCF方面公开任何类。

由于您有一个Web应用程序，这可能会更安全。

Answer 2

您可以尝试RIA服务

http://www.silverlight.net/getstarted/riaservices/

我正在使用的是这个。

创建WCF服务

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项目中）：

命名空间BusinessLayer { [服务合约] 公共接口IService { [OperationContract的] void DoWork（）; } }
修改使用界面的现有实现（这是您现有的代码）：

命名空间BusinessLayer { 公共类服务：IService { 公共无效DoWork（） { } } }

Answer 3

为什么要将整个业务逻辑层包装在WCF层中？在进入这种新方法之前，我会仔细研究你的理由。您是否有物理原因导致您无法绕过访问需要在DMZ之外的数据库的业务逻辑？如果是的话，好的。但如果没有，我会考虑采用这种方法来开始。

话虽如此，如果您没有其他选择，我将避免使用包含UI所需的每个公共方法的单片WCF类。首先，我将在Web应用程序端引入一个接口，以便您可以依赖UI中的摘要而不是具体实现。此外，我将研究使用WCF REST服务。您可以使用ServiceRoute来避免引入任何* .svc文件。然后，您可以使用WebGet / WebInvoke属性修饰要公开的方法。这可能会节省大量编码。

Answer 4

这是错的。您的服务不应超过20个操作。如果您需要完全相同的操作，则应为每个业务类创建合同和服务包装器。这通常导致繁琐的接口，这对于分布式场景来说不是好的解决方案。在这种情况下，您应该将服务层建模为外观，将多个调用合并为一个。

WCF设计方法

4 个答案: