Здравствуйте, vermouth, Вы писали:

V>Здравствуйте, dmitry_npi, Вы писали:

_>>Вопрос — как совместить хорошую производительность и хороший дизайн. С точки зрения дизайна, мне кажется, что данный класс должен иметь у себя такой метод, там ему самое место. Но с другой стороны, если каждый экземпляр полезет в базу, будут тормоза. Как быть? Есть какой-то типовой прием?

V>Самый стандартный приём когда нужно отвязать доменную модель от инфраструктуры это связка из Unit Of Work и Detached Interface. Detached Interface заставляет интерфейс UnitOfWork объявляеть в доменной модели, а реализацию в сервисном слое, таким образом исключается циклическая зависимость между пакетами, и инициатором обращения к инфраструктуре как и положено является сервисный слой, так как реализация UnitOfWork помещается в него. В метод сущности для которого возможна понадобиться дополнительная информация передаешь инстанс UnitOfWork и если сущности что-то понадобиться она запрашивает это у UnitOfWork но ей не обязательно ничего знать об оптимизации, так и о том что она не единственная кто поработает с этим экземпляром UnitOfWork.

А как это все избавит от множественных обращений?
Например у тебя БЛ находится в методе класса сущности. Логика дергает базу. Естественно логика в классе сущности не знает что есть еще сущности, которые обрабатываются аналогично.

Правильно решение — выполнить один апдейт, который запишет нужные данные в БД. Это вроде как только bltoolkit умеет делать.
Для других ORM — можно получить список обрабатываемых сущностей, пробежаться по ним, сформировать запрос и вытащить данные, нужные для вычислений.

Путь с использованием доменной модели — каждый раз бегать в базу. Даже если сделать кеш, то не факт что он поможет, а заранее тянуть в память все значения, которые могут понадобиться при вычислении — все равно что сразу вытянуть всю базу из памяти и работать с ней. Только в таком случае нарываемся на множество проблем с конкурентным доступом. Такой подход работает для маленьких и простых задач.