Выбор технологии для LOB-приложения с автономной моделью и моделью «программное обеспечение как услуга»

Question

Заранее извините за стену текста!

Сценарий:

Мы смотрим, какую технологию выбрать для LOB-приложения, которое должно поддерживать «автономную» модель(frontend + backend работает на настольном компьютере), а также режим локального сервера (backend установлен на локальном сервере), а также программное обеспечение как услуга через Интернет (backend установлен на хост-сервере).

Мымы хотим свести к минимуму работу по разработке, поэтому выбрали интерфейс Silverlight.Мы намерены повторно использовать одну и ту же кодовую базу для всех 3 моделей.

LOB-приложение сильно загружает ввод данных и выполняет некоторую математическую работу с бэкэндом.У нас будет большое количество просмотров.И у нас будет база данных с более чем 80 таблицами.В настоящее время у нас есть собственный DAL, который позволяет нам использовать MSSQL, MySQL и Oracle в качестве СУБД.

В настоящее время мы стремимся использовать приложение Agile TDD Silverlight 4.0 MVVM в качестве интерфейса в C # с инфраструктурой Caliburn.И иметь службу WCF (RIA?) В качестве бэкэнда (не Silverlight, обычный .NET 4.0).Это хорошо подходит для разных моделей, так как это только вопрос, где установлен бэкэнд.Для модели SAAS у нас в Интернете есть сервер, на котором может находиться серверная часть.

Вопросы:

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

2. Что касается бэкэнда, мы рассматриваем службы RIA WCF, но хотели бы иметь «Безопасность сообщений», которая делаетне представляется возможным в реализации WCF Silverlight.Является ли WCF RIA правильным выбором?Или обычный WCF «лучше» в отношении безопасности каким-либо образом?

3. Что касается различных СУБД, которые мы должны поддерживать.Это жизнеспособно делать с WCF RIA Services?Или нам лучше создать свой собственный BLL / DAL и выставить его себе с помощью простого WCF?

4. Есть ли у кого-нибудь опыт установки нескольких СУБД без использования встроенного SQL, а только хранимых процедур?Исходное приложение сильно зависит от встроенного SQL, но нам интересно, насколько это приложение будет обслуживаться только с хранимыми процедурами в разных СУБД.

5. Последний вопрос, касающийся MVVM и безопасности:мы хотели бы «спрятать» как можно больше нашей логики в бэкэнде из соображений безопасности / защиты кода.Что было бы логичным для этого сделать?Нам нужно сделать TDD, поэтому мы должны иметь возможность макетировать модель, а это значит, что она должна быть доступна во внешнем интерфейсе.Но нам нужна вся логика, чтобы быть в бэкэнде.Должны ли мы просто использовать «оболочку» во внешнем интерфейсе, которая «связывает» «реальную модель» во внутреннем интерфейсе?Вид фиктивной модели, которая подходит 1-на-1 к базовой модели.Или есть «лучший» способ сделать это?

Заранее благодарим за любую помощь, которую вы можете оказать нам по любому из этих предметов!

Гурон.

Answer 1

1. Это должно быть жизнеспособно, но вы должны действительно продумать модель коммуникации.Сценарий SaaS является наиболее ограничивающим и чувствительным к безопасности, поэтому вам следует начать с него и перейти к полностью локальной настройке.

2. Я бы посоветовал против служб RIA.Как часто бывает в случае с MS, это хорошо для простых вещей, но вы достаточно скоро столкнетесь с его ограничениями и проклянете.См. здесь , чтобы узнать, как сделать безопасность сообщений в SL.

3. Как и в вопросе 2: я бы не пошел с RIA, но даже если вы это сделаете, вы можетеиспользуйте Entity Framework и держите его независимым от СУБД.

4. Я, например, фанат хранимых процедур.Да, это создает несколько точек развертывания (и неизбежный риск различий в версиях), но я всегда говорю «держать SQL в SQL».

5. К сожалению, то, что вы описываете, является распространенным явлениемпроблема в TDD систем сопряжения.Я бы использовал макет клиента для тестирования сервера, а затем использовал реальный сервер для тестирования клиента.

Answer 2

Вот что мы выбрали для нашего LOB - локальное / клиент-сервер / приложение saas:

1. Это оказалось чрезвычайно жизнеспособным.У нас очень мало исключений, большая часть кодовой базы точно такая же, для локального, клиентского сервера и saas.

2. Мы решили не использовать WCF RIA, а использовать обычные вызовы WCF.мы используем «TransportWithMessageCredential» для защиты связи.

3. Мы используем Entity Framework для предоставления базы данных нашему бэкэнд-приложению.Там у нас есть доменный слой и наши пользовательские классы «Entity», которые мы заполняем на основе получаемых классов EntityFramework.

4. Поскольку мы используем Entity Framework, все наши операторы SQL полностьюушел.Мы используем Linq, чтобы выбрать то, что мы хотим.Пока это работает отлично.Так что больше нет встроенного SQL.А благодаря введению отдельных слоев (Entity Framework -> Context context -> Mapper Class -> Entity Class) мы получаем высокую ремонтопригодность.

5. Мы максимально упростили внешний интерфейс,Имеющиеся у нас ViewModels строго используются для заполнения всех связанных свойств, поэтому у View есть данные для работы.Все решения в отношении того, какие данные или что возможно, выполняются в бэкэнде.Весь поток приложения выполняется классом Manager в бэкэнде, который использует дуплексное соединение WCF, чтобы сообщить интерфейсу, что делать.