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

Question

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

到目前为止，我已使用此 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 时，我更喜欢像 DTO 一样使用 POCO 实体。现在，对于外部应用程序或不同的 UI，我构建了不同的服务层——它将在流程 BL 和 DTO 中使用相同的来获取数据。但是，我更喜欢为服务提供单独的数据协定类。

分离背后的逻辑是 BL 层 API 可以更健谈（作为进程内层），而服务 API 将基于无状态的块状交互。您可以通过服务公开有限的功能和/或不同的 API（因为潜在的印象是服务将被外部应用程序使用）。将 DTO 和 DataContract 分开也是可取的，因为两者都可以在不同的时间以不同的方式发生变化。数据协定变更必须得到控制和版本控制，而这可能不适用于 DTO（或域对象）。

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

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