Question

我刚刚开始使用web.api处理WCF服务项目，以便为我们现有的asp.net mvc Web应用程序的移动版本公开数据。

到目前为止，我已使用此WCF web.api getting started tutorial来运行某些内容，并在ServiceContract中创建了假数据。

服务合同如下：

[WebGet(UriTemplate = "")]
    public IQueryable<Workspace> Get()
    {
        //I want to use our existing service layer like this:
        //WorkspaceService service = new WorkspaceService();
        //service.ReturnAllWorkspacesByUsername("mary");

        //this is fake data for testing
        var workspaces = new List<Workspace>()
        {
            new Workspace() {Id = new Guid(), Title = "Implement WCF Web Services"},
            new Workspace() {Id = new Guid(), Title = "Add APIs to WebService"},
            new Workspace() {Id = new Guid(), Title = "Map Routes"},
            new Workspace() {Id = new Guid(), Title = "Expose Resources"},
        }; 
        return workspaces.AsQueryable();
    }

我想尽可能使用现有的mvc应用程序，如何最好地使用现有的服务层和域模型，或者最好不要使用？分离服务会更好吗？

有人能为我指出一些好的初学者教程吗？

谢谢，启

Answer 1

我更喜欢拥有一个通用的进程内业务逻辑层。 DTO（数据传输对象）用于跨层通信。当数据访问层基于EF时，我更喜欢使用PTOO实体作为DTO。现在，对于外部应用程序或不同的UI，我构建了不同的服务层 - 它将在进程BL和DTO中使用相同的服务层来获取数据。但是，我更喜欢为服务提供单独的数据合同类。

分离背后的逻辑是BL层API可以更加繁琐（处于进程中层），而服务API将基于无状态的大块交互。您可以通过服务公开有限的功能和/或不同的API（因为潜在的印象是外部应用程序将使用服务）。 DVDs＆amp; amp; DataContract分开，因为两者都可以以不同的方式和不同的时间发生变化。数据合同更改必须进行控制和版本化，而相同可能不适用于DTO（或域对象）。

就移动UI而言，它不需要使用服务，而是直接依赖于进程内BL层。如果您的原始MVC应用程序是分层的，那么这是可能的。

另一个观察 - 从WCF服务返回IQueryable没有意义。您可以返回一组对象，如果需要，客户端应用可以转换为IQueryable。

WCF Web服务和从数据库检索 - 使用现有的asp.net服务层？

1 个答案: