Сколько бизнес-логики принадлежит сервисного слоя RIA?
Я экспериментировал недавно с Silverlight, RIA Services и Платформой Объекта с помощью.NET 4.0. Я пытаюсь выяснить, имеет ли тот стек смысл для использования в каком-либо из моих предстоящих проектов. Конечно, кажется, что эти технологии могут быть очень продуктивными для разработки приложений, но я изо всех сил пытаюсь решить, как должно быть спроектировано приложение сверху этого стека.
Основной вопрос, который я имею, - то, что в большинстве демонстраций я видел, что большая часть бизнес-логики заканчивается как DataAnnotations и пользовательские проверки в классе обслуживания домена RIA Services. Это кажется несоответствующим мне. Я просматриваю доменный сервис как в основном прославленный веб-сервис, который, оказывается, помогает продвинуть информацию клиенту. Но большая часть того, что я видел, кажется, ориентирует доменный сервис как основной источник бизнес-логики в приложении.
Так, мои вопросы:
- Каково лучшее расположение для бизнес-логики (правила, проверки, поведения, авторизация) в приложении с помощью этого стека?
- Там какие-либо инструкции публикуются на архитектурном уровне для использования этого стека?
Мои вопросы принадлежат большим, сложным, и долговечным приложениям. Очевидно, для приложения только нескольких экранов это - меньше беспокойства.
Править: Другая вещь, которую я означал упоминать, состоит в том, что, очевидно, можно сделать доменный класс обслуживания глупым, но затем Вы теряете большую автоволшебную информацию об объекте (например, проверки) продвигаемый клиенту. И затем если Вы проигрываете, который является там какой-либо точкой к использованию сервисов RIA?
2 ответа
Наша команда находится в процессе реализации приложения Silverlight поверх стека RIA. Мы решили построить модель предметной области на основе сущностей RIA. Кроме того, мы решили следовать шаблону MVVM для моделирования взаимодействия пользовательского интерфейса.
Пока что я заметил следующие преимущества:
- Доменные классы - хорошее место для размещения бизнес-логики, включая сложные проверки.
- Классы домена используют объекты и контекст RIA в качестве интерфейса для хранилища данных.
- Доменные классы смоделированы с учетом бизнес-задач и не требуют однозначных отношений с объектами RIA.
- Простые проверки пользовательского интерфейса могут жить в моделях просмотра.
Также следует отметить, что мы реализовали нашу собственную карту идентификации для параллелизма и перенесли грязное отслеживание в контекст RIA.
На практике эта архитектура требует немного больше усилий по кодированию, но окупается за счет удобочитаемости и ремонтопригодности. Я бы придерживался этой практики даже для простых приложений CRUD. Возможность построить модель предметной области, которая более точно представляет проблемное пространство, является неоспоримым преимуществом.
В целом с технологией работать продуктивнее, чем против нее.
Как вы говорите, бизнес-логика заканчивается DataAnnotations и настраиваемыми проверками, это может быть «лучшим» местом для нее с точки зрения производительности разработчика для первой версии системы.
У меня есть ощущение, что эта технология имеет силу при быстром создании грубых приложений, когда у вас сложная бизнес-логика, вы можете получить дополнительный бизнес-уровень между приложением Silverlight и службами RIA.
Мы еще не пытались построить что-то реальное из этого, мы действительно узнаем ответ на этот вопрос только после того, как воспользуемся им в течение некоторого времени.