代码之家 › 专栏 › 技术社区 › Jacob

避免web服务神类

refactoring soap wcf .net

Jacob · 技术社区 · 16 年前

这是操作词。到目前为止,这导致了一个可怕的上帝类,其中包含131个[OperationContract]方法,甚至还有更多的私有方法。

所以,为了对其他程序员友好,并可能享受一些我不知道的由此产生的好处,我想重构这个怪物。以下是我看到的可用选项:

我不喜欢的是,这会破坏我的客户端代码。我必须重写它以使用新的代理类。此外,我还需要维护更多的WCF配置(真恶心!)。此外,对于共享私有方法应该属于哪里,可能会有监护权之争。

选项2:使用分部类

这个想法似乎对我很有吸引力。我会用这种方法做的是让每个源文件(不是也其中许多)代表了web服务的功能划分。例如:

MyService.svc.cs
MyService.AccountManagement.svc.cs
MyService.Preferences.svc.cs
MyService.MediaManagement.svc.cs

选项3:我没有考虑过的事情

我假设一个复杂的web服务创建这样的神类并不罕见,所以一定有一些我不知道的好的实践方法。你们都使用了哪些技术来使你们的web服务类更容易上手?

更新

6 回复 | 直到 16 年前

Community Mohan Dere 9 年前

这向我表明,您的WebService服务于两个角色,逻辑和接口。..但事实上,它可能只服务于一个,即逻辑中的接口。

更新:

在为什么应该重构和/或如何设计类库方面 S.O.L.I.D principles

查看上面的链接,它将提供所有原则的摘要。

这是一些 SO discussions 如果有人有更好的链接,请告诉我,干杯

Robert Koritnik 16 年前

有时这是不可行的,而且会使事情变得更加复杂,但既然你知道你的代码库,你就是那个在这里打电话的人。在这种情况下(在与分析开发人员进行了一次头脑风暴后),部分类文件仍然是一个更好的选择。

有一件事是肯定的。您的服务必须 编辑: 代码不仅用于执行,还用于维护。如果很难找到你的路,那肯定是不可维护的。)

关于这一点 为什么 它们是一个问题。

将您的服务视为web应用程序用户界面。就像web应用程序使用BLL类及其与整个解决方案的单个问题/方面相关的封装功能一样,您的web服务也应该如此。它应该是一个也使用BLL类及其原子功能的接口。它不是可视化界面,而是API。

Lucero 16 年前

Christian Hayter 16 年前

web.config .svc 指向实现类的文件。

重新分解的示例 .svc

<%@ ServiceHost Service="Fully.Qualified.Name.Of.Implementation.Class" %>

svcutil.exe ChannelFactory<IContract>

Mark Seemann 16 年前

为了为RIA客户端提供服务,这可能不是问题,因为这只是一个实现细节——基本上,使用SOAP的唯一原因是它是一种可互操作的传输机制。

无论如何,我同意Robert的观点:服务必须重构。

eglasius 16 年前

关于您的选项/评论:

选项2+地区:正如你所说,你有单独的应用程序。这些不应该属于同一类,命名一些模式并不能很好地推销它。看看这个系列,因为它是一个关于许多事情的旅程 http://blog.wekeroad.com/category/mvc-storefront (从第一章开始)-这对我帮助很大。你也可以在solid上查看这本电子书- http://www.lostechies.com/content/pablo_ebook.aspx

正如其他人所说,您的服务代码应该只是一个很小的层,可以转换为适合服务的格式和应用程序逻辑。考虑学习单元测试,当你一直在使用这样的代码时,这些似乎很荒谬,因为它几乎会妨碍你很好地使用它。这将不断提醒你/指出你的代码都绑在哪里了。