Переход на N-уровневую архитектуру с WCF?

Question

Я работаю в крупном государственном правительственном агентстве, которое чуть отстает от времени. Наши навыки устарели, а замораживание бюджета препятствует обучению или найму новых сотрудников / консультантов (увольнение также невозможно). Проектирование бизнес-объектов, реализация шаблонов проектирования, создание библиотек и сервисов кода, модульное тестирование, управление исходным кодом и т. Д. - все это вы не найдете здесь. Мы получили 0 баллов на тесте Джоэла, насколько это возможно. Хорошей новостью является то, что мы можем подняться только отсюда!

Мы разрабатываем настольные CRUD-приложения (на C ++, C # или Java), которые обращаются к базе данных Oracle напрямую через соединение ODBC. У нас в основном GUI завален операторами SQL и лоскутным кодом. Нам было сказано перейти к сервисно-ориентированной n-уровневой архитектуре, чтобы предотвратить прямой доступ к базе данных и устранить потребность клиента Oracle на пользовательских машинах.

Является ли WCF тем путем, по которому мы должны идти? Мы сделали несколько пошаговых описаний приложений n-уровня (например, this ), и они кажутся простыми в реализации, но мы просто не знаем достаточно, чтобы понять, рассматриваем ли мы даже правильные технологии. Использование сгенерированных .NET типизированных наборов данных .NET кажется хорошим временным промежутком, который позволяет нам сэкономить месяц / годы работы (в отличие от создания новых бизнес-объектов с нуля для многочисленных проектов). Этот консервативный подход жизнеспособен для первого шага?

Answer 1

Я недавно начал использовать службы WCF для своего уровня данных в некоторых веб-приложениях, и я должен сказать, что это разочаровывает в начале (в первую неделю или около того), но оно того стоит, когда код развернут.

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

Из описания среды, в которой вы находитесь, я уверен, что вы сразу же поймете эту выгоду.

Answer 2

CSLA может подойти для ваших настольных приложений N-Tier. Он поддерживает WCF, имеет большое сообщество разработчиков и хорошо документирован. Это очень объектно-ориентированный.

Answer 3

Взгляните на Entity Framework (поскольку для него уже есть пара поставщиков Oracle) в сочетании с .NET 3.5 SP1, которая позволяет встроенную сериализацию WCF для ваших сгенерированных классов EF.

Вот хороший блог для начала: http://blogs.msdn.com/dsimmons

Answer 4

Прежде всего, я бы определенно , а не (извините за упор) беспокоился о времени, которое вы сэкономите, набрав DataSet по сравнению с созданием ваших собственных бизнес-объектов. Обычно это не то место, где вы будете проводить большую часть времени на разработку. Я предпочитаю использовать бизнес-объекты самостоятельно.

В вашей ситуации я бы сначала хотел реализовать концептуальное подтверждение. Тот, который решает все проблемы, с которыми вы можете столкнуться. Это подтверждение концепции должно реализовывать весь сценарий использования, начиная с клиента, извлекая данные из базы данных и возвращая их клиенту. Прежде чем продолжить, вы должны быть уверены в своей реализации.

Тогда о выборе технологии. WCF, безусловно, является хорошим выбором для связи между вашими клиентскими приложениями и уровнем обслуживания. Я полагаю, что и ваши клиенты, и ваш сервисный уровень станут приложениями на C #? Это намного упрощает задачу, поскольку совместимость между различными платформами (например, Java / C #) все еще не тривиальна, хотя в большинстве случаев должна работать.

Answer 5

Последняя компания, в которой я работал, выбрала WCF практически по той причине, которую вы описали выше. Для WCF есть много хорошей документации и книг, относительно легко начать работу, и WCF поддерживает множество опций конфигурации.

Могут возникнуть некоторые головные боли, когда вы начнете пытаться согнуть WCF для работы способом, специально не разработанным для коробки. Обычно это проблемы конфигурации. Но такие сайты или IDesign могут помочь вам в этом.