0

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

  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 上。我将重构我的几个 Web 应用程序以使用 Azure。

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

4

1 回答 1

1

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

  1. 将应用程序移植到 Azure 的原因是什么？如果您真的以可伸缩性为目标，您可能真的需要一个松散耦合的分布式应用程序。目前尚不清楚您当前的架构是否真的是分布式应用程序之一，例如，如果您的所有层都必须托管在一台机器上，或者耦合得如此松散，以至于可以分布在多个处理单元上。在 Azure 的情况下，您必须调整架构以至少了解分布式环境，例如处理超时或单层之间的连接/消息丢失。是的，如果你想在每一层之间建立健壮的通信，你必须明确地为它做一些事情（使用带有队列或服务总线的消息ETC。）

  2. 安全呢？用户（如果有的话）如何在您的应用程序中验证自己的身份？您可能想要使用Azure AD 服务，在虚拟机上运行您自己的 AD 控制器，或者让您的本地 AD 控制器可用于您的实例（这可能有点棘手）。

  3. 您使用的终极数据存储是什么？根据此存储的类型（关系数据库、非关系数据库等），您可能希望使用 SQL Azure 作为数据的 RDBMS 或在云中运行 MongoDB，或者表和 blob 存储也可以。同样，必须牢记这一点（例如，为 EF 配置重试和超时策略）。

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

于 2013-05-20T20:29:47.797 回答