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

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

Сценарий:

Мы смотрим, какую технологию выбрать для LOB-приложения, которое должно поддерживать "автономную" модель (frontend + 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. Что касается серверной части, мы изучаем службы WCF RIA, но хотели бы иметь "Безопасность сообщений", что, по-видимому, невозможно в реализации WCF в Silverlight. Является ли WCF RIA правильным выбором? Или обычный WCF "лучше" в отношении безопасности в любом случае?

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

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

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

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

Гурон.

Источник

2 ответа

Решение

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

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

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

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

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

Источник

Вот что мы выбрали для нашего 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, чтобы сообщить интерфейсу, что делать.

Источник
Другие вопросы по тегам