Как потреблять данные в крупномасштабном бизнес-приложении

Question

Мне просто интересно, что лучше всего подходит для использования данных из многоуровневого крупномасштабного приложения. Честно говоря, у меня все еще недостаточно опыта, чтобы выбрать правильный путь. Мы начали наш проект с мысли, что RIA Services будет распространять сущности через провод, и сначала мы были в порядке с RIA, но проблемы начались после того, как нам пришлось отправить какой-то сложный DTO в качестве ответа от службы и как параметры для сервисные вызовы.

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

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

Новый архитектор присоединился к нашей команде, и теперь мы рассматриваем возможность использования его собственной письменной реализации ServiceBus. Он выглядит намного более зрелым, но он построен вокруг DuplexPushService, и я не знаю, будет ли он масштабируемым и надежным, как говорит автор.

Почему я пишу это? - Я просто хочу услышать историю успешной интеграции шаблона или технологии в готовое решение, какую технологию вы используете для поддержки бизнес-логики? Можете ли вы сказать об этом за и против? Что бы вы сделали, если бы вы начали новый проект Silverlight прямо сейчас?

Буду очень благодарен за ваши ответы, спасибо за чтение этой стены текста и извините за отсутствие образцов кода и ссылок.

Таким образом, реальный вопрос заключается в том, как использовать данные в приложении silverlight, которые должны обслуживать ~ 50 тыс. Человек.

Answer 1

Золотое правило

• Ничего не делать, пока производительность на самом деле не является проблемой.

Bonus правило

• дизайн так только один WCF призыв DTO является требуется в случае использования (если это возможно).

DTO не являются объектами, поэтому не рассматривайте их так как в обоих концах. Преобразуйте их в нечто более удобное, а не используйте их напрямую.

Когда производительность действительно проблема

1. Cache столько, сколько вы можете в SilverLight приложения
2. Использование Local Storage и синхронизации для сохранения данных между сеансами.

Answer 2

Похожие на JGauffin. Мы принимаем DTO и «загружаем» их в «Модели», которые наследуют OnPropchange, DataErrorInfo и т. Д., Которые мы затем используем в наших моделях ViewModels. Самое чистое могло бы сказать, что наша модель на самом деле является lightweigh ViewModel, но я думаю, что это модели. Мы берем записи из LINQ2SQL и преобразуем их в объекты CRUD (из-за старого школьного пути, который мы использовали для этого), и отправляем его поверх простой старой службы SilverLight WCF. Этот объект DTO становится нашим «.Source» в объекте, к которому все свойства указывают (установите Source.Property = значение и верните Source.Property;). С EF мы обязательно не будем включать include из-за наших ассоциаций, мы закончим в рекурсивном цикле, A имеет B, в котором B имеет ссылку на его родительский элемент, который имеет B .... и т. Д. И т. Д. И т. Д.