Насколько бизнес-логика принадлежит сервису RIA?

Question

Недавно я экспериментировал с Silverlight, RIA Services и Entity Framework, используя .NET 4.0. Я пытаюсь выяснить, имеет ли этот стек смысл для использования в любом из моих будущих проектов. Конечно, кажется, что эти технологии могут быть очень продуктивными для разработки приложений, но я изо всех сил пытаюсь решить, как приложение на вершине этого стека должно быть спроектировано.

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

Итак, мои вопросы:

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

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

Edit: Еще одна вещь, которую я хотел упомянуть, это то, что вы, очевидно, можете сделать класс обслуживания домена глупым, но тогда вы потеряете много информации об автоматических сущностях (например, проверки), передаваемой клиенту. И потом, если вы потеряете, есть ли смысл пользоваться услугами RIA?

Answer 1

Наша команда находится в процессе внедрения приложения Silverlight поверх стека RIA. Мы решили построить модель предметной области поверх сущностей RIA. Кроме того, мы решили следовать шаблону MVVM для моделирования взаимодействий пользовательского интерфейса.

Пока что я заметил следующие преимущества:

1. Доменные классы - хорошее место для размещения бизнес-логики, включая сложные проверки.
2. Доменные классы используют объекты RIA и контекст в качестве интерфейса для хранилища данных.
3. Классы доменов смоделированы с учетом бизнес-задач и не требуют однозначных отношений с объектами RIA.
4. Простые валидации пользовательского интерфейса могут жить в ViewModels.

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

На практике эта архитектура требует немного больше усилий при написании кода, но окупается и удобочитаема. Даже для простых приложений CRUD я бы следовал этой практике. Возможность построить модель предметной области, которая более точно представляет проблемное пространство, является неоспоримым преимуществом.

Answer 2

В целом работать с технологией эффективнее, чем с ней.

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

У меня такое ощущение, что эта технология имеет свои преимущества при быстром создании сложных приложений, когда у вас сложная бизнес-логика, вы можете получить дополнительный бизнес-уровень между приложением silverlight и службами RIA.

Пока не пытались создать что-то реальное в этом, мы действительно узнаем ответ только после того, как используем его в течение некоторого времени.