Re[6]: Domain Model, мапперы и отчеты
От: Аноним  
Дата: 21.04.08 12:32
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Не обязательно доменные объекты напрямую биндить на гриды. За пол часа можно наваять SomeObjectInfo который предоставит доступ только к нужным элементам.


A>Сортировку по любому полю легко сделать самостоятельно (см. конец поста).

A>А с фильтрацией действительно траблы. Хотя ничего не стоит получать данные уже отфильтрованными (да не всегда удобно, но это "не всегда" всего 5% от всех запростов) (девекспресовский грид умеет сам фильтровать и сортировать, правда он платный, зараза).

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


A>Сборка объекта не стоит ничего по сравнению с обращением к базе.

A>Про идентефикаторы ничего не понял
A>В большинстве случаем память занимаемая объектом == памяти занимаемой всеми его частями (ну может еще несколько байт, но это фигня).


Вот смотрите, требутся пользователю найти клиента (что-бы отредактировать или что-нибудь в этом роде) — вводит в фильтр имя Игорь, и в ответ ему из БД приезжает 1000 записей с Игорями. Зачем мне материализовывать всю тысячу ? Из них он выберет только одну запись (на самом деле конечно просто введет еще одно условие фильтра, так что вся эта тысяча объектов вообще будет не нужна), которую я и превращу в объект.
Кроме того, раз уж мы потратились на материализацию, было-бы логично их закэшировать, но я думаю не стоит говорить, во что может вырасти этот кэш после дня работы.
Если-же их не кэшировать, то что-то слабо представляю, как это все будет работать — получили 1000 записей из БД, материализовали, получили смесь из новых объектов, не подлежащих кэшированию, и "старых" объектов, которые уже были в кэше. Отдали эту гремучую смесь клиенту, который возьмет и сохранит часть этих объектов. Потом он делает новый запрос к реестру, получает еще тысячу объектов, у части которых уже есть клоны ... В общем муть какая-то получается

A>Никто не говорит, что нужно забрать из базы все что касается искомого объекта. Есть Lazy Load.


кстати если не материализовывать подобные поисковые результаты, то в ряде случаев можно и без lazy load обойтись — приложение проще станет.


A>И все же хочу уточнить, что я не против ДатаТэйблов. Когда нужно просто посмотреть и отредактировать данные по скорости и удобству (поддержка .Net) им нет равных, но вот когда в просмотр и редактирование вкрадывается логика... Лучше сразу от них отказываться (ИМХО).


а ведь нету никакой особой логики-то, получили список искомых записей, выбрали нужную. Зачем нам для этого объекты ?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.