Хочеться простого и красивого: мапить поля на объекты и обратно не с помощью гигантского switch в DAO классах и не переопределив методы Save в DAO классе. Хочется так же, чтобы соответствие свойтво-класс было прописано где-нибуть недалеко от класса и было бы интуитивным и понятным для людей, недавно начавших работать с кодом.
Как принято это делать? Каждый объект учить сохранять самого себя? А не будет ли размазанный по коду доступ к базе вылазить боком потом?
Я сначала думал — воспользоваться каким-нибуть ORM, генерящим автоматом код. Потом — написать своих аттрибутов к свойствам объектов и как-то reflection-м обходить свойства объекта при сохранении — но не будет это медленно?
Помогите советом пожалуйста.
... << RSDN@Home 1.2.0 alpha rev. 0>>
15.10.05 00:35: Перенесено модератором из 'Философия программирования' — AndrewVK
Здравствуйте, oleksab, Вы писали:
O> Хочеться простого и красивого: мапить поля на объекты и обратно не с помощью гигантского switch в DAO классах и не переопределив методы Save в DAO классе. Хочется так же, чтобы соответствие свойтво-класс было прописано где-нибуть недалеко от класса и было бы интуитивным и понятным для людей, недавно начавших работать с кодом.
O> Как принято это делать? Каждый объект учить сохранять самого себя? А не будет ли размазанный по коду доступ к базе вылазить боком потом?
Ну... обычно делают некий класс-менеджер (классы-менеджеры), которые берут на себя работу по загрузке/сохранению, а сам класс за это не отвечает (transparent persistence).
А вообще вам, батенька, надо почитать про object-relational mapping, т.к. как раз оно. У того же Фаулера в "Patterns of Enterprise Applications Architecture" написано немного в тему. Вот ещё в NHibernate Wiki есть топик про документацию, т.ч. и ссылки на статьи по O/R-Mapping.
Я думаю не будет размазанный, если обьединить все обьекты, общающиеся с базой в отдельный уровень Data Access Level
O> Как принято это делать? Каждый объект учить сохранять самого себя? А не будет ли размазанный по коду доступ к базе вылазить боком потом?
и понятно и быстро, советую.
O> Я сначала думал — воспользоваться каким-нибуть ORM, генерящим автоматом код. Потом — написать своих аттрибутов к свойствам объектов и как-то reflection-м обходить свойства объекта при сохранении — но не будет это медленно?
O> Помогите советом пожалуйста.
Здравствуйте, oleksab, Вы писали:
O>Здравствуйте.
O> Хочеться простого и красивого: мапить поля на объекты и обратно не с помощью гигантского switch в DAO классах и не переопределив методы Save в DAO классе. Хочется так же, чтобы соответствие свойтво-класс было прописано где-нибуть недалеко от класса и было бы интуитивным и понятным для людей, недавно начавших работать с кодом.
O> Как принято это делать? Каждый объект учить сохранять самого себя? А не будет ли размазанный по коду доступ к базе вылазить боком потом?
O> Я сначала думал — воспользоваться каким-нибуть ORM, генерящим автоматом код. Потом — написать своих аттрибутов к свойствам объектов и как-то reflection-м обходить свойства объекта при сохранении — но не будет это медленно?
O> Помогите советом пожалуйста.
Я же предпочитаю сам писать и под конкретный проект дорабатывать.
Однако со второго-третьего проекта ты будешь использовать неизменное ядро — каторое будет тебя целиком устраивать и по производительности и по функционалу и т.д.
Тем более ты знаешь каждую мелочь. Тебе не надо переучиватся под какую-нить, мягко скажем, некрасивое решение
Теперь я имею супер-скоростнуй систему ORM поддерживающую ассоциации LazyLoad и проч веши
производительней чем все популярные фрэймворкт (NHibernate, Gentle, DataObjects .NET) до 50%
Здравствуйте, undead00, Вы писали:
U>Оцените свой скилл. U>Это раз.
Мне тяжело со стороны. Где-то посередине, наверное.
U>Я же предпочитаю сам писать и под конкретный проект дорабатывать.
угу. Велосипед своими руками. В общем-то я и спрашивал как раз об этом — как строятся такие системы. Но скорее не с целью писать что-то свое, а найти написанное "правильно".
U>Однако со второго-третьего проекта ты будешь использовать неизменное ядро — каторое будет тебя целиком устраивать и по производительности и по функционалу и т.д.
Согласен. Но вот написать это — займет достаточно много времени.
U>Теперь я имею супер-скоростнуй систему ORM поддерживающую ассоциации LazyLoad и проч веши U>производительней чем все популярные фрэймворкт (NHibernate, Gentle, DataObjects .NET) до 50%
А как оно работает (в двух словах) расскажи пожалуйста? Интересен механизм mapping-a свойств на поля (и обратно) и составления sql выражений для сохранения/вычитки объектов из базы.
Здравствуйте, undead00, Вы писали:
U>Здравствуйте, oleksab, Вы писали:
U>Оцените свой скилл.
U>Это раз.
U>Я же предпочитаю сам писать и под конкретный проект дорабатывать. U>Однако со второго-третьего проекта ты будешь использовать неизменное ядро — каторое будет тебя целиком устраивать и по производительности и по функционалу и т.д.
U>Тем более ты знаешь каждую мелочь. Тебе не надо переучиватся под какую-нить, мягко скажем, некрасивое решение
U>Теперь я имею супер-скоростнуй систему ORM поддерживающую ассоциации LazyLoad и проч веши
U>производительней чем все популярные фрэймворкт (NHibernate, Gentle, DataObjects .NET) до 50%
Только вы вряд ли имеете систему, которая позволяет решать такой круг различных задач, как это позволяют тот же Hibernate.
Цель фрэйморка — дать возможность получить общее решение. Никто не мешает его доработать.
