使用Azure时，我应该更改.Net MVC应用程序的结构吗？

Question

在我目前的开发模型中，我通常使用以下解决方案结构：

  D     
  a 
  t ---- Presentation (MVC, WCF, WPF)
  a            |
    --- Business Logic
  M            |            
  o ----- Data Access (Repositories & Unit of Work)
  d            |
  e ------- Entities (EF or nHibernate)
  l
  s

我知道存在EF是您的存储库和UOW的论点，但我发现将它们排除在您的业务逻辑之外仍然是有利的。

我开始将我的开发工作转移到更多关注使用Azure。我将重新考虑几个我的网络应用程序以使用Azure。

我想知道是否有任何令人信服的理由重新思考我构建解决方案的方式？

Answer 1

以下是在将应用程序移植到Azure时可能会记住的一些建议：

1. 将应用程序移植到Azure的原因是什么？如果您真的希望实现可伸缩性，那么您可能真的需要一个松散耦合的分布式应用程序。目前尚不清楚您当前的架构是否真的属于分布式应用程序，例如如果所有图层都必须托管在一台机器上，或者如此松散地耦合，可以分布在多个处理单元上。在Azure的情况下，您必须调整您的架构，以至少了解分布式环境，例如处理单层之间的超时或连接/消息丢失。是的，如果您希望在每个层之间进行强大的通信，则必须为其明确执行某些操作（使用带有queues或service bus等的消息。）

2. 安全性如何？用户（如果有的话）如何在您的应用程序中验证自己？您可能希望使用Azure AD Services，run you own AD controller on a Virtual Machine或使您的内部部署AD控制器可用于您的实例（这可能有些棘手）。

3. 您正在使用的最终数据存储是什么？根据此存储的类型（关系数据库，非关系数据库等），您可能希望将SQL Azure用作RDBMS对于您的数据或运行MongoDB in the cloud或maybe table and blob storage would do。同样，必须记住这一点（例如，为EF配置重试和超时策略）。

4. 您的托管模式和虚拟化级别是什么？根据所需的虚拟化级别 - 从Iaas到PaaS - 您可能需要记住您的应用程序可能是在任意时间点关闭并重新生成，并完全重置所有本地驱动器存储。因此，如果您依赖某些（临时）本地存储的数据，您可能希望将存储机制更改为Azure提供的机制（如BLOB或表存储）。