ASP.NET Web API体系结构建议/反馈

目前我正面临构建Web服务的需求，该服务将使Java客户端通过httprequest获取并触发对我们数据的操作。我们是一个.Net商店，它的最新解决方案是Microsoft的MVC4 Web API。我习惯了你的标准分层架构，我从API中抽取了数据，但这将是我的第一个提供数据的Web服务。ASP.NET Web API体系结构建议/反馈

从我的研究，我所看到的建议如下：

逻辑和数据访问分离成一个单独的项目类型的类库。
使用您的控件访问数据并执行逻辑。
使用您的模型来访问数据和执行逻辑。

我正在寻找有经验的MVC4 Web API的人员，他们可以通过这种方式了解构建Web服务的良好实践。

在此先感谢。

来源

2012-11-07 vikingben

欢迎来到stackoverflow！我认为这个问题有点含糊。你能解释一下你究竟想做什么吗？例如：“我的Web服务的设计应该是什么？这就是我的想法”？也许......这个问题似乎太开放了。 – Parris

感谢您的回应和欢迎。我担心我的问题的模糊性与我对MVC 4产品的知识相符。我在想两个选择。第一种选择是将我的逻辑和数据访问分离为单独的类库项目，以便重用代码和更好的组织。或者，另一种选择是使用MVC shell，并使用该模型来实现业务逻辑和数据访问，因为这个项目变得越来越大，我觉得可能会变得非常拥挤。 – vikingben

ASP.NET Web API！= ASP.NET MVC http://www.tugberkugurlu.com/archive/newsflash-asp-net-web-api-does-not-sit-on-top-of-asp-net- mvc-in-fact-it-do-not-sit-of-top-of-anything只是FYI :) – tugberk

首先，请将您的ASP.NET Web API逻辑放入一个单独的项目中。这将使您比托管层更灵活（因为ASP.NET Web API托管不可知），它只是使整个项目变得清晰。假设你的项目名称是MyProject。您可以将该API项目命名为MyProject.API，并且您可以将Microsoft.AspNet.WebApi.Core NuGet软件包安装到此项目中。

我还建议你分开你的域图层（POCO实体，存储库，你的服务层件等）。我们称之为MyProject.Domain。然后，您可以参考MyProject.API项目的MyProject.Domain项目。

我不会推荐你将所有的POCO实体转储到你的API中。所以，我肯定会使用数据传输对象（Dto）。您可以使用像autoMapper这样的第三方工具将您的实体类映射到您的Dtos。但是，请将您的Dtos，请求命令，请求模型放入单独的项目中。您可以参考MyProject.API项目MyProject.API.Model项目。为什么我们为此创建一个单独的项目？因为，稍后如果您决定为您的HTTP API构建.NET客户端封装器，则可以轻松地引用此项目以将其用于.NET客户端。我们称这个项目为MyProject.API.Model。

最后，我们需要我们的API的托管层。如果您希望在ASP.NET下托管此项目，则可以通过空Web应用程序模板创建一个新项目，并将其称为此项目MyProject.API.WebHost。然后，您可以将Microsoft.AspNet.WebApi包安装到此项目中。从这个项目中，您可以参考MyProject.API,MyProject.API.Model和MyProject.Domain项目。该项目是您应该部署到您的服务器的项目。

如果您想为HTTP API创建.NET包装器，则可以创建另一个名为MyProject.API.Client的项目并将Microsoft.AspNet.WebApi.Client包安装到此包中。你也可以参考MyProject.API.Model这个项目，这样你就可以反序列化并从强类型对象序列化。

这里是解决方案浏览器，因为我一直在与项目工作的截图：

enter image description here

希望这给你一点想法的。

来源

2012-11-08 09:02:25 tugberk

你的反馈。我很欣赏快速反应。 – vikingben

： - \这真的开始听起来像https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition –

@DanEsparza让我知道，如果这些层中的任何一个对你没有意义，我会告诉你为什么它在那里。 – tugberk

ASP.NET Web API体系结构建议/反馈

回答

相关问题