Выбор правильной архитектуры .NET. WCF? WPF/Forms, ASP.NET(MVC)?

Im в ситуации, когда я должен спроектировать и реализовать довольно большую систему снизу. У меня есть некоторые (на самом деле) вопросы об архитектуре, на которые я хотел бы получить ваши комментарии и мысли.

Я не надеюсь, что Ive написал слишком много здесь, но я хотел дать вам общее представление о том, что такое система.

Краткая информация о приложениях, прочитайте, если хотите: я не могу поделиться много подробностей о проекте, но в основном это система, в которой мы предлагаем нашим клиентам услугу по управлению своими пользователями. У нас есть горячая линия, в которой пользователи звонят, и наша горячая линия использует приложение (окно) для интуиции для управления данными пользователей и т.д. У клиента также есть веб-приложение, где они могут видеть отчеты, информацию об их бизнесе и пользователях, а также способность изменять свои данные. Изменение данных - это не только данные пользователя, такие как адрес и т.д., Но также информация о продуктах/услугах, которые могут быть у пользователя, что может быть затруднено.

Приложения будут построены на Microsoft.NET Framework 4 с базой данных MS SQL Server 2008. Будет доступно несколько приложений, которые должны получить доступ к этой базе данных, например:

Интранет-приложение (используется нами и нашей горячей линией)
Клиентское веб-приложение типа 1
Клиентское веб-приложение типа 2
Тип клиентского веб-приложения n разных приложений)
...

Теперь моя большая проблема заключается в том, какие части .NET я должен использовать для такой системы. Для "бэкэнд" Ive рассмотрел использование Windows Communication Foundation: Будет ли WCF хорошим выбором?

Приложение интрасети будет приложением, которое должно редактировать множество записей в базе данных. Его нужно легко перемещать с помощью клавиатуры (быстро работать). Имеет такую функцию, как "найти клиента, найти это, найти это, выбрать это и обновить". Какой был бы лучший выбор для разработки этого приложения? Будет ли это WPF или старые добрые Windows Forms? Мне не нужны все графические функции в WPF, такие как 3D, но приложение должно выглядеть красиво (может быть, что-то вроде новых инструментов Visual Studio/Office).

И тот же вопрос касается веб-страниц. У них много работы, но не так много функций, как приложение интрасети, а не столько же данных (гораздо меньше).

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

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

Изменить 1: Похоже, что многие согласны с тем, что мы должны использовать WCF. Когда вы вводите ORM-картупер в слое данных и уровень сервиса с использованием WCF, должно быть достигнуто повышение производительности? У вас есть какие-либо комментарии по этому поводу?

Еще один вопрос, который вызывает всплытие, заключается в том, как мы обрабатываем аутентификацию и роли. Приложение интрасети имеет "главный" доступ (без ограничений). Однако, когда клиент получает информацию из веб-приложения о своих пользователях, то, что возвращается, зависит от того, что их "уровень обслуживания" и несколько других параметров, связанных с клиентом. Каков наилучший способ справиться с этим? Существуют ли какие-либо образцы/лучшие практики?

Ответ 1

Технология рабочего стола для рабочего стола

WPF является невероятно мощным и, несомненно, является лучшим выбором для данного типа приложения, которое вы описываете. Если ваша команда не имеет опыта работы с WPF на кривой обучения за несколько месяцев, но долгосрочные выгоды от повышения производительности и ремонтопригодности делают ее хорошо стоящей. Единственная причина, по которой вы можете рассматривать что-либо, кроме WPF, - это если у вас ограниченный срок, и ваша команда уже хорошо знает некоторые другие технологии. Даже в этом случае я бы рассмотрел возможность разработки версии WPF параллельно и рассмотрел другую версию как прототип.

Некоторые люди занимаются разработкой настольных систем, используя Silverlight вместо WPF, по теории, что они должны использовать одну технологию вместо двух. Я не согласен с этим аргументом: эти две технологии настолько схожи, что навыки и передача кода очень хорошо, WPF в настоящее время имеет много очень полезных функций, отсутствующих в Silverlight, и по мере того, как Silverlight получает эти функции, он имеет тенденцию копировать то, что хорошо из WPF. Таким образом, в конечном итоге любые потраченные усилия и код, созданные при разработке приложений WPF, не будут потрачены впустую.

Также обратите внимание, что WPF может работать как в браузере так и в Silverlight. Когда я создаю веб-приложения для клиентов, которые, как я знаю, будут работать под Windows, я выбираю WPF поверх Silverlight. В настоящее время я собираюсь преобразовать кучу приложений Windows в веб-приложения WPF для упрощения развертывания.

Технология веб-интерфейса

Вы были бы глупым использовать ASP.NET MVC в веб-приложении, если бы вы могли использовать Silverlight. Вещи, которые занимают несколько дней в ASP.NET MVC, занимают часы или минуты на Silverlight. Вещи, которые занимают дни в Silverlight, занимают годы в ASP.NET MVC.

Проникновение рынка Silverlight в настоящее время составляет около 50% и растет на 2-3% в месяц, и оно будет работать на 99% настольных компьютеров. К следующему году проникновение может составлять 85% или выше. Вы должны взвесить риск того, что некоторые пользователи не будут загружать Silverlight и не будут получать доступ к вашему приложению в отношении рисков, связанных с ASP.NET MVC: с ASP.NET MVC ваше приложение будет стоить намного дороже, и вам потребуется больше времени выйти на рынок, иметь меньше возможностей и меньше "богатства".

Тем не менее, если бы был контракт, я действительно, действительно, действительно хотел, и клиенту было неудобно использовать Silverlight, я, вероятно, вернусь к ASP.NET MVC в качестве своего второго выбора. Но только если веб-раздел приложения был относительно небольшим.

Технология связи

WCF - хороший выбор для обслуживания ваших данных. В настоящее время это лучше, чем конкуренция, достаточно быстро и хорошо интегрируется с Silverlight, XBAP и WPF. Если у вас нет веских оснований для выбора другой технологии веб-сервисов, я бы пошел с WCF.

Что касается эффективности, то бинарный форматировщик WCF примерно так же эффективен, как и все, что вы найдете, и более эффективен, чем обычные прямые протоколы доступа к базе данных, такие как TDS для шаблонов использования, с которыми вы столкнетесь. Если вам нужно использовать форматтер SOAP для совместимости, вы потеряете некоторую пропускную способность при преобразовании в XML, но в противном случае это будет относительно эффективно.

Я использую слой данных под названием "Emerald Data Foundation", который я создал и планирую открывать с открытым исходным кодом в ближайшие несколько месяцев. Он использует те же объекты в веб-службе и на клиенте и ведет себя одинаково независимо от того, подключен ли он к внутренней базе данных. Это работает очень хорошо, потому что вы почти не понимаете, что есть коммуникационный уровень. Такой подход делает слой данных чрезвычайно простым.

Emerald Data Foundation также имеет механизм контроля доступа на основе ролей, который позволяет клиентам получать доступ к данным на основе отношений между объектами данных, так что, например, человек может получить доступ только к своим собственным данным клиента. Это выполняется на уровне данных, поэтому разработка уровня пользовательского интерфейса не может случайно отображать данные, которые не должны быть замечены или сделать несанкционированные обновления.

Ответ 2

Эта конструкция выглядит в высшей степени выполнимой.

WCF является хорошим кандидатом для уровня сервиса, приятно видеть, что происходит некоторый возраст ORM, и у вас есть веская причина иметь основанный на форме и веб-интерфейс.

WPF может (по существу) вести себя как форма Windows. Тем не менее, MS рекомендует его над Win Forms, если вы пишете что-то новое.

ASP.NET MVC - отличный кандидат на веб-контент - страницы не имеют статуса и у вас гораздо больше контроля над страницей.

Ознакомьтесь с отдельными обсуждениями типа "WPF VS WinForms".

Ответ 3

Вы рассматривали услуги Silverlight + RIA? - это естественный выбор для n-уровневой системы с богатым пользовательским интерфейсом. Вы можете использовать его как для интрасети, так и для приложений, ориентированных на клиента.

Ответ 4

Как упоминалось выше Sohnee, я считаю, что ваш логический архитектурный подход довольно прочный, и я думаю, что WCF - это "выбор". Я уверен, что вы получите свою долю мнений относительно технологий презентации и ORM. Я предлагаю пару элементов на уровне сервиса, где я трачу много времени на приложения, очень похожие на ваши:

Если вы еще этого не сделали, начните смотреть AppFabric. Это где Microsoft собирается с хостингом сервисов WCF и предоставляет вам множество преимуществ, таких как высокоскоростная аппаратура и управление сервисами, которые теперь вы не получаете из коробки с WCF.
Подумайте, какой тип протокола (и, следовательно, привязки WCF) вы сможете использовать на основе вашей сетевой инфраструктуры и ваших деловых партнеров. Если вы можете использовать TCP в качестве высокоскоростного транспорта, вы будете в отличной форме, если он будет работать с вашей сетью.
Рассмотрите возможность интеграции MSMQ в вашу логическую архитектуру для обеспечения очереди и гарантированной доставки. У Juval Lowy есть отличные материалы по интеграции MSMQ в его книгах WCF.
Теперь начните думать о своих сервисных интерфейсах и стратегии управления версиями. Решения, принятые на ранней стадии в этих областях, становятся почти неизменными после их совместного использования с деловыми партнерами.
При участии нескольких бизнес-партнеров подумайте о том, как вы собираетесь защищать эти службы. Группа Microsoft P & P только что выпустила довольно хорошее руководство по идентификации на основе утверждений и контролю доступа, которые могут быть действительно полезны для вас на основе ваших сценариев интеграции.

Надеюсь, это поможет. Не стесняйтесь публиковать комментарии, если вам нужна дополнительная информация.

Ответ 5

Если ваша команда еще не имеет опыта работы с WPF, я бы рекомендовал придерживаться WinForms для настольного клиента, предполагая, что у вас есть давление по расписанию (и какого проекта нет?) WPF чрезвычайно эффективен, но он также имеет крутая кривая обучения. Я использовал его для относительно небольших проектов с низкой видимостью, и это дало мне свободу действительно узнать, как использовать технологию, а не пытаться взломать что-то вместе, как если бы это были только WinForms с более красивыми элементами управления.

У меня нет большого опыта работы с WCF, но я понимаю, что там есть много кривой обучения. Как и в WPF, это вопрос того, что знает ваша команда и сколько времени вы можете инвестировать в освоение новой технологии.

Ответ 6

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

Если это только приложение ввода данных, вы можете просто создать несколько экранов и жить с ним. Это будет самая простая вещь, которая может работать.

С другой стороны, если причины, по которым изменения данных ценны для бизнеса, я бы сначала подумал о создании модели твердого домена. А затем слой команд поверх него. Клиентское приложение выдавало команды для изменения данных, например "Дайте пользователю Xxx повышение зарплаты", которое будет одобрено, а затем обработано. Такие команды были бы первоклассными гражданами в вашей архитектуре.