服务层& Web API服务层?

时间:2014-01-22 19:03:22

标签: web-services design-patterns asp.net-web-api restful-architecture

我有一个应用程序,其中包含用于数据访问,业务和wcf服务的层。我需要将此WCF层转换为Web API,并且我是否应该坚持:

1)创建两个服务层/项目: - 服务(班级图书馆) - Services.Api(用于公开和包装对服务类库的调用的WebAPI)

2)或者,只需创建一个WebAPI项目。

我想我在#2中看到的问题是它限制了我如何重用库 - 我只能使用REST来使用服务。使用#1,我可以根据需要在我的Web控制器和客户端/ ajax上的WebAPI中使用类库。我在#1中看到的问题是重复调用服务层类库所需的所有额外代码。

希望有意义。请让我知道你对我可能会采取什么样的好方法和做法的想法,或者因为我缺乏理解而尖叫我。感谢

3 个答案:

答案 0 :(得分:4)

如果您有一个好的业务层,它本身应该是您的服务(类库)层。在您的业务/服务层上,应该是您的前端层,可以是Wcf,Api或Mvc。

ProjectName
 -ProjectName.Core (All poco classes and interfaces)
 -ProjectName.Data (All entity framework stuff)
 -ProjectName.Service (All business logic)
 -ProjectName.Web (All font end logic)

答案 1 :(得分:0)

选项1为您提供了更多可重复使用的代码,我认为这几乎总是一件好事。

答案 2 :(得分:0)

您的问题不应仅仅从另一个API变体的角度来考虑。

我会选择1)。

当系统复杂性增加,API版本化可能成为问题,单元测试等等时,服务与通信部分的分离将带来许多好处。

一些额外的想法:调用图层不是Services.Api,而是更明确地表示它公开的端点类型,并通过限制Api图层中可用的引用来强制关注点分离当开发人员在系统发展时偷工减料(即不访问Api项目中可用的存储库,域或DTO模型等)时,避免混淆问题的可能性。

如果你这样做,我认为代码的重复可以非常小。