带有存储过程的 ASP.NET WEB API 数据访问层

Question

我对 MVC 框架和 ASP.NET WEB API 非常陌生

我一直在使用具有 n 层架构的 ASP.NET AJAX 构建 Web 应用程序，并且仅将数据作为存储过程。

我们正在尝试升级我们的产品之一以使用 HTML5 ASP.NET WEB API 进行开发，我们希望保持我们的 DAL 和存储过程完好无损，并在顶部使用 ASP.NET WEB API 或 WCF 数据服务添加服务层DAL 和 HTML5 表示层将命中数据的服务层。

您能否建议我们是否希望保持数据库存储过程和 DAL 完好无损？

我注意到 EF5 中对存储过程的支持需要更加成熟才能支持我们的一些具有多表数据集的存储过程，我知道对此有解决方法。我已经看过 EF 6 Alpha 规范，我对这些功能感到很兴奋。

是否有任何人有指向数据访问层之上的 ASP.NET WEB API 服务层的教程或示例的链接？或者你能提出一些建议或指出正确的方向吗

如果我必须大胆猜测我想如何为我们当前的问题实施解决方案。我会说。

Present DAL 为我们提供了 Dataset 和 DataTable 数据集中的包装器以转换为 IQueryable 并在 ServiceLayer 中使用它们跳过整个 EF 解决方法。

提前致谢

Answer 1

实际上你可以做到这一点。您可以将您的服务逻辑放入 Web API，但是，我不会这样做。我宁愿再增加一层抽象，以保持 API 尽可能轻量和简单。根据你的情况，你有这样的事情：

1. 带有存储过程的后端数据库服务器
2. 用于处理 1 号后端数据库的数据访问层组件。

现在您想在 2 之上构建 API。我对您的建议是添加服务层（也称为业务逻辑层），您可以在其中放置额外的逻辑，如计算、必要时额外的验证、消息传递服务等。

然后在服务层之上，我将添加 Web API。所以最后你的分层可能是这样的：

1. 带有存储过程的后端数据库服务器
2. 用于处理 1 号后端数据库的数据访问层组件。
3. 服务层（业务逻辑）
4. ASP.NET Web API
5. HTML5 客户端

这背后的想法是，在未来的某个时候，当您需要为您的产品添加其他功能时，您可以在服务层中进行。不要继续增加 Web API 的复杂性。考虑维护、测试和未来的扩展。