0

What we're wanting to do is use typical POCO objects over a service. Now, I know that services are really made to provide functionality ala carte, but really, the issue that we're trying to address here is achieving the same usability that you get with a class library (POCO functionality like attributes, constructors, and behaviors in a compiled library) along with the benefit of having a centralized, reusable assembly that is called "on the fly". That way, we can build the libraries, and re-deploy it to ONE location and all apps that reference it will be updated.

It would seem that WCF doesn't really support this, and I can understand why. In most cases, people tend to scoff condescendingly and ask "why would you do that?". Well, I've answered that here. So what I'm really asking is where should look into to achieve this sort of "central class library"? I don't feel like services are the answer, but I need to achieve a central class library that can be accessed like a service. This way, an update of that class library would transparently affect all applications that reference it vs. having to re-reference it in every app. Does this make sense? TIA

UPDATE: Just thought about it. Would it be stupid to just add the assembly to the application server's GAC?

4

1 回答 1

0

我最终做的是创建一个围绕 Web 服务的类库。所有业务逻辑都保留在类库中，而所有数据访问都通过服务完成。这隐藏了客户端编程中任何复杂的乒乓球，并使得一些非常简单和干净的页面。

在旁注中，事实证明在 WCF 服务中创建的对象仍然支持抽象，因此我能够稍微利用它。我为具有匹配类库对象的服务数据传输对象创建了一个命名约定。库对象具有与服务对象相同的属性名称，以及它们需要执行的任何其他内容（我将它们按区域分隔）。

所以我认为这是对服务的更正确使用，并且几乎解决了我的问题。相当多的额外工作，但现在我们有了一个更灵活的架构，它既松散耦合又高度内聚。

于 2012-06-06T22:16:42.240 回答