1

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

到目前为止，我已经使用这个WCF web.api 入门教程来运行一些东西，并在 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 应用程序，如何才能最好地使用现有的服务层和域模型，或者最好不要这样做？分开服务更好吗？

任何人都可以为我指出一些好的初学者教程吗？

谢谢，凯

4

1 回答 1

0

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

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

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

IQueryable另一个观察结果 -从 WCF 服务返回没有意义。您可以返回一组对象，并且客户端应用程序可以IQueryable根据需要进行转换。

于 2011-07-07T05:45:59.730 回答