Ориентация как на облачные, так и на самостоятельные приложения?

Question

Я планирую создать приложение, которое может быть размещено заказчиком традиционным способом или в облаке (SaaS).

Поскольку между этими двумя целями много различий, каким руководствам я должен следовать, чтобы уменьшить будущие проблемы?

Я особенно думаю о постоянном хранилище ... С одной стороны, у меня есть традиционная СУБД (SQL Server, Oracle и т. Д.) Или, возможно, системы nosql, такие как MongoDB, couchDb и т. Д., А с другой стороны, у меня есть для работы с «проприетарным» и специальным хранилищем (Azure Table, Sql Azure в мире MS).

У меня такое ощущение, что это будет возможно, но с большим количеством МОК, но, поскольку я новичок в облаке, я буду признателен за любые отзывы.

Конечно, я хочу (оптимистично?) Иметь возможность легко переключаться между подходами ...

ТНХ

Answer 1

Вы думаете о правильных линиях.Когда вы разрабатываете свое решение для конкретной платформы, вы должны нацелить инкапсуляцию зависимостей таким образом, чтобы потребитель конкретной функциональности платформы был защищен от реализации. Именно здесь вы делаете такие вещи, как

• Создатьпривлечение к интерфейсам платформы.
• Используйте контейнеры IOC или любой другой подход для разделения компонентов.
• Четкое отделение кода, относящегося к платформе, от другой логики.Например, если вы используете библиотеку хранилища Azure, сохраните код обработки хранилища в отдельном проекте.

Проще сказать, чем сделать, но то же самое можно сказать и о Azure.Если команда знает об этих фактах во время проектирования и разработки, у вас может быть решение, которое можно перенести на любую платформу виртуализации.

Answer 2

SQL Azure - это большое подмножество SQL Server. С точки зрения программирования они по существу эквивалентны (например, SP, таблицы, индексы, триггеры и т. Д.).

Есть несколько вещей, которые не включены сегодня или отличаются (например, нет CLR, нет Sql Broker, ограничения по размеру). Вы можете написать приложение, которое минимизирует или устраняет зависимость от этих неподдерживаемых функций, и ваше приложение станет более «переносимым».

Таблицы Windows Azure (и другие компоненты хранения) относятся к Windows Azure. Вам нужно будет инкапсулировать компоненты, которые их используют, и предоставить совместимый интерфейс для других частей вашего приложения, которые зависят от них. Классическим примером являются компоненты доступа к данным. Или доступ в очередь для асинхронной связи.

IoC / DI могут помочь, но они не обязательны.