WCF RIA навязывает плохой дизайн?

Question

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

В качестве примера, чтобы максимально использовать RIA, я нахожу, что вы в значительной степени должны зависеть от вашей модели данных от начала до конца.Лучшие функции WCF RIA (такие как сквозная проверка и интеграция EF) требуют, чтобы вы представляли модель данных Entity Framework практически как есть, вплоть до уровня представления.Это исключает разработку вашего программного обеспечения с использованием шаблона Service Layer , средств отображения данных или DTO.Я также изо всех сил (пока что безрезультатно) создаю приложение с истинной моделью предметной области из-за ограничений в EF.

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

Помимо этих проблем, общеизвестно, что WCF RIA практически невозможно протестировать.Классы DomainContext не скрываются за интерфейсами, и это чрезвычайно сложно из-за отслеживания изменений и других тонкостей.В каждом отдельном случае, который я видел в дикой природе, ViewModels в конечном итоге принимают прямые зависимости от реализации DomainContext.Даже когда эта зависимость внедряется в конструктор, она не имеет смысла, потому что не может быть разумно подделана.

Так что я полагаю, мой вопрос двоякий: обеспечивает ли WCF RIA плохой дизайн?Если да, есть ли разумные обходные пути, которые не приведут к тому, что я потеряю большинство преимуществ платформы?А если нет, может кто-нибудь указать мне на литературу, которая показывает, как создавать хорошие проекты на основе проверенных образцов с использованием WCF RIA?

Answer 1

Вы можете перефразировать вопрос как «Могу ли я взять свой пирог и съесть его?».

За 30 с лишним лет я много раз видел этот цикл: -

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

Такие инструменты, как RIA, Lightswitch, WebMatrix и т. Д., Находятся в лагере 4-го поколения. По замыслу они обеспечивают особый способ выполнения определенных задач, чтобы исключить повторение и позволить разработчикам быстро справиться с работой. Разработчики обмениваются идеальным дизайном на скорость разработки. Этот компромисс такой же, как и сам старый компьютер.

Итак, чтобы ответить на ваш вопрос, нет, вы не можете съесть свой торт и съесть его. Вы либо делаете вещи их способом и используете службу RIA WCF, либо вы делаете вещи своим способом и создаете свои собственные Услуги WCF. Существует некоторая золотая середина (как всегда), где вы можете использовать RIA WCF, а затем прыгать через обручи, заставляя его делать то, что вы хотите.

Кстати, EF предлагает значительную абстракцию (хотя и с большими усилиями) между моделью, которую он в конечном итоге представляет, и вашей фактической схемой базы данных. Например, он позволяет вам представить отношение «многие ко многим» без промежуточного класса.

Answer 2

Ответ на этот вопрос «Нет». Это не навязывает «плохой дизайн». Это просто конкретный инструмент в вашем наборе инструментов, и он предназначен для решения конкретной проблемы. Вы говорите как кто-то, кто пытается взять молоток и использовать его, чтобы просверлить отверстие, и сказать: «Почему эта штука не делает хорошую дыру в моей стене?» Ммм .. Потому что это молоток. Он предназначен для другой работы ...

Большая часть наших навыков как разработчиков заключается в том, чтобы найти правильный инструмент для работы. Silverlight и RIA имеют свое применение, но они не волшебная серебряная пуля.

Я думаю, что вы смотрите на технологию с неправильными целями. И я говорю это как парень, который является большим поклонником TDD, MVC и т. Д. Я написал свою долю приложений, которые используют DTO, репозитории, слои, абстракции и т. Д. Я также написал довольно много Silverlight и RIA за последние несколько месяцев.

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

Я решил посмотреть на некоторые из моих ViewModels в некоторых недавних проектах в Silverlight. Вот что я обнаружил: все, что я делаю на ВМ, в значительной степени делегирует то, что Silverlight уже делает для меня: привязка данных, наблюдение за изменениями свойств, запрос контекстов данных, сохранение изменений в контексте данных, проверка сущностей и уведомление GUI и т. Д. .

Silverlight и RIA уже выполняют эти задачи для меня. Я просто делегирую звонки! Если бы я написал модульный тест, я бы тестировал Silverlight и RIA - не моя логика домена! Мне не нужно тестировать фреймворк - я предполагаю, что MS знает, что они делают.

Если у вас достаточно сложности для того, чтобы гарантировать DTO, средства отображения данных, уровни обслуживания и т. Д. ... Тогда вам, вероятно, нужно подумать о чем-то другом, кроме Silverlight и RIA. Знаешь что я говорю?

Правильный инструмент для работы человека. Выберите правильные инструменты.

Answer 3

Эти ссылки могут вам помочь.

Использование DTO

Unit testng

Архитектура