EagerReadDerivation: балансировка преимуществ с издержками

Question

Я изучаю проект, основанный на домене и распределенный DDD для предстоящего приложения Silverlight. Я буду работать. Шаблон EagerReadDerivation похож на то, что он улучшит масштабируемость приложения, но ценой повышенной сложности.

Приложение будет иметь потенциально тысячи пользователей, загружающих большие текстовые файлы (100 000 строк), которые необходимо обработать несколькими службами. Нам также нужно будет поддерживать сценарии «что если» (a la ParallelModel). Я считаю, что подход, основанный на модели, поможет нам справиться со сложностью, поэтому я хотел бы как можно больше оставить логику из базы данных.

Мой вопрос предназначен для разработчиков, которые попытались создать шаблон EagerReadDerivation: он окупился за вас, и стоило ли вам дополнительной сложности в вашем приложении?

Answer 1

Чтобы оценить преимущества, вы должны учитывать коэффициент загрузки/запроса. Если у вас есть дополнительные запросы, кроме загрузок, вы должны определенно применить обработку при загрузке.

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

В любом случае, оставьте логику из базы данных по мере планирования.