Лучший подход к написанию корпоративного приложения с Windows и веб-интерфейсами?

Question

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

В прошлом мы использовали RemoteApp/RemoteDesktop для общения с локальным приложением Windows Forms, запущенным на сервере. Простой, но неуклюжий.

• Некоторые аспекты приложения должны быть представлены в виде веб-приложения.
• Некоторые аспекты приложения должны быть представлены в виде приложения Windows Forms.

Приложение Windows должно быть распространено среди географически разрозненных аудиторий (менеджеров филиалов и сотрудников).

Вот задачи интерфейса:

1. «тонкого клиента», где он ведет себя похожим на веб-браузер (пользователь только интерфейс)
2. вся обработка будет сделано на сервер
3. использовать ту же кодовую, что веб-приложение делает - просто различный интерфейс
4. Непосредственная развиваться (легко поддерживать и расти)

Каковы некоторые из лучших подходов к этому?

(я потратил изрядное количество времени, смотря на .NET Remoting, а затем WCF, но я не имею clairty опыт, который я надеюсь, что вы можете принести.)

Спасибо!

Answer 1

У меня есть приложение на работе с веб-интерфейсом и интерфейсом службы WCF. В другом приложении (WinForms) используется служба WCF для предоставления той же функциональности, что и в веб-приложении, только в контексте того, что делает приложение WinForms. Самое приятное в этом состоит в том, что фактическая функциональность находится в бизнес-слое, и как веб-приложение, так и служба WCF просто представляют другой способ доступа UI &.

От того, что вы описываете, что-то подобное будет работать. Настоящий ключ заключается в том, чтобы как можно меньше логики бизнеса внедрялись в ASPX-страницы. Любой, что есть, вам придется воссоздать для него сторону WCF.

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

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

Сначала я начну с его веб-приложения, и как только он сделает то, что вы хотите, вы можете добавить службу WCF впоследствии, чтобы сохранить проект в управляемом масштабе.

Что касается WCF и удаленного доступа, в этом случае я бы предпочел WCF. Он ДЕЙСТВИТЕЛЬНО хорошо работает с веб-приложениями.

редактировать:

1) Интерфейс - Вам нужен класс в SVC-файл для реализации услуг не вызывает ни на что. Интерфейс необходим в качестве контракта на обслуживание для некоторых видов услуг (basicHTTPBinding, который основан на SOAP), но не для других (webHTTPBinding, основанный на REST). Я бы, вероятно, написал интерфейс, хотя он позволяет вам изменить реализацию сервиса, не меняя контракт на обслуживание, что и должно оставаться последовательным для клиентов.

2) Конечно, можно вызвать услугу из веб-приложения, но это добавит дополнительный уровень работы в веб-приложение. Для служб HTTP это также означает, что ваш сервис будет XML-сериализовать все, тогда ваше веб-приложение должно будет десериализовать его немедленно. Сериализация XML несет значительный успех. Я бы избегал этого метода, поскольку веб-приложение может привязывать к бизнес-объектам, которые бизнес-объекты возвращаются бизнес-уровнем, более эффективно (и WCF будет автоматически сериализовать XML для клиентов службы). Одно дело, если ваше веб-приложение нужно было бы вызвать другую услугу в другом приложении, но в этом случае это не путь.

3) Если это публичное лицо, то как вы его аутентифицируете. Для внутреннего использования вы можете позволить IIS обрабатывать аутентификацию с помощью Active Directory. Если у вас есть интернет-клиенты, они, вероятно, не находятся в Active Directory, и вам нужно будет использовать другой метод. (HTTP Basic и Digest auth все равно должны быть в порядке, или вы можете сделать что-то вроде добавления имени пользователя/пароля в качестве параметров к методам, требующим аутентификации. Обязательно используйте SSL в сервисе!)