同时针对云和自托管应用程序？
我计划构建一个应用程序，该应用程序可以由客户以传统方式托管，也可以在云中 (SaaS) 托管。
由于两个目标之间存在许多差异，我必须遵循哪些准则来减少未来的问题？
我特别考虑持久性存储...一方面，我有传统的 RDBMS（SQL Server、Oracle 等）或者可能是 nosql 系统，如 MongoDB、couchDb 等，另一方面，我必须使用“专有”和特定存储（Azure Table，MS 世界中的 Sql Azure）。
我感觉这是可能的，但需要大量的 IOC，但由于我是云的新手，我将不胜感激任何反馈。
当然，我希望（乐观？）能够轻松地在方法之间切换......
谢谢
I'm planning to build an application that can be either hosted by the customer in a traditional manner or in the cloud (SaaS).
As there are many differences between the two targets, what are the guidelines I have to follow to reduce future problems ?
I'm especially thinking about the persistence store... In one hand I have traditionnal RDBMS (SQL Server, Oracle, etc.) or maybe nosql systems like MongoDB, couchDb, etc. and in the other hand, I have to work with "proprietary" and specific storage (Azure Table, Sql Azure in the MS world).
I have the feeling it will be possible but with a lot of IOC, but as I'm new to the cloud, I'd appreciate any feedbacks.
Of course, I want (optimistic?) to be able to quite easily switch between approaches...
thx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你正在思考正确的路线。当您围绕特定平台设计解决方案时，您应该以一种方式封装依赖项，使平台特定功能的使用者免受实现的影响。这是您执行诸如
接口。
解耦组件。
从其他逻辑。例如，如果使用 Azure 存储库，请将存储处理代码完全保留在单独的项目中。
说起来容易做起来难，但这同样适用于 Azure。如果团队在设计和开发过程中了解这些事实，您就可以拥有一个可以迁移到任何虚拟化平台的解决方案。
You are thinking around the correct lines. When you designing your solution around a specific platform you should target the encapsulate the dependencies in a way that the consumer of the platform specific functionality is shielded from the implementation.This is where you do things like
intefaces.
decouple components.
from other logic. For example if using Azure storage library keep the storage handling code in a seperate project altogether.
Easier said than done, but same holds good for Azure too. If the team is aware of these facts during design and development, you can have a solution which can be migrated to any virtualization platform.
SQL Azure 是 SQL Server 的一个大子集。从编程的角度来看，它们本质上是等效的（例如SP、表、索引、触发器等）。
有一些东西目前尚未启用或有所不同（例如，没有 CLR、没有 Sql Broker、大小限制）。您可以编写一个应用程序来最大限度地减少或消除对那些不受支持的功能的依赖，并且您的应用程序将更加“可移植”。
Windows Azure 表（以及其他存储组件）是 Windows Azure 特定的。您将需要封装使用它们的组件，并为依赖于它们的应用程序的其他部分提供兼容的接口。一个典型的例子是数据访问组件。或异步通信的队列访问。
IoC/DI 可以提供帮助，但它们不是强制性的。
SQL Azure is a large subset of SQL Server. From a programming perspectivem they are essentially equivalent (e.g. SP, tables, indexes, triggers, etc).
There are a few things which are ot enabled today or are different (e.g. no CLR, no Sql Broker, size limitations). You can write an app that minimizes or eliminates the dependency to those unsupported features and your app wil be more "portable".
Windows Azure Tables (and the other storage components) are Windows Azure specific. You will need to encapsulate components that use them and provide a compatible interface to other pieces of your app that depend on them. A classic example is the data access components. Or queue access for asynch communication.
IoC/DI can help but they are not mandatory.