MVC、WCF、EF的应用程序架构

本文关键字：应用程序 EF WCF MVC | 更新日期: 2025-02-18 03:55:20

我正在开发一个web应用程序，稍后我们还计划开发并提供其移动应用程序。我不是一个经验丰富的人，但只是基于我的理解，计划拥有这个架构：

  1. MVC Web项目前端，将直接与WCF通信服务
  2. 服务器端验证将在MVC模型上使用数据注释进行，然后数据将传递到WCF层。使用客户成员资格提供程序的安全性也将在MVC中实现
  3. WCF层也将像业务层一样工作。如果需要，它将与DAL通信，DAL是一个类库
  4. 使用EF的DAL将与SQL Server通信*

问题请

  1. 这个架构好吗
  2. 将WCF用作业务层和服务层好吗
  3. 我们应该在哪一层实现哪些模式
  4. 对于数据验证和安全，MVC是正确的位置吗

感谢

编辑5.关于单元测试，它好吗？或者为了更好的测试，我应该做一些改变？

MVC、WCF、EF的应用程序架构

您所描述的是一个非常现代且良好的Microsoft服务器堆栈。

ASP.net MVC是一个非常适合你的web UI。如果你使用的是asp.net MVC，你还应该研究业务层的asp.net webapi（new）。

http://www.asp.net/web-api

http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

SQL Server和EF是相当标准的。另一种选择是纯T-SQL，如果您需要最终的控制并且对直接SQL感到满意的话。

将web UI（MVC）与业务层（web api）分离的一个附带好处是，即使最初它们恰好位于同一个角色/机器上，也可以独立地分离角色和扩展。此外，客户端的html/javascript代码可以对web api进行ajax风格的调用。出于这个原因，您可能想要"注册"（config）webapi服务器的端点。如果以后扩展/移动它，就不会有代码更改——从第一天开始，代码就完全分离了。

移动设备（如果是厚应用程序）可以直接使用web api。除非移动应用程序是一个使用嵌入式浏览器/javascript解决方案的混合移动应用程序，否则它只是MVC web UI的一个小尺寸消费者。

对于测试，您可以在自己的命令行过程中自托管webapi，并在可行的情况下模拟数据。这将允许您在没有后端的情况下验证web UI。通过拥有一个业务层（通过web api公开），您还可以验证后端&独立于UI的逻辑（应该是您的大部分逻辑）。

相关文章：