Здравствуйте, Аноним, Вы писали:
OLE>>Ну.... .Нет лет на 10 моложе А>Не на 10, а на 5. .NET вышел в 2000году. А по существу?
Это означает, видимо, что НЕТу всего-то лет пять...
IMHO:
1. По ORM-маппингу можно воссоздать схему данных с нуля.
2. ORM маппинг позволяет облегчить автоматизированное тестирование.
3. На ORM маппинг есть открытые стандарты, как де-факто так и де-юро.
4. ORM маппинг позволяет действительно инкапсулировать логику, любую, не только бизнес.
5. ORM маппинг и Domain Model не исключают использования рекордсетов, а точнее их аналогов, обратное видимо неверно.
6. ORM маппинг решает большее число проблем на этапе компиляции, но это уже не любой. В recordsetaх все рантайм.
Субъективно ORM-маппинг более масштабируемая технология.
И более "серверная".
На мой взгляд у НЕТа только одно преимущество, там отлично реализована работа в offline. Этого не хватает ORM-контейнерам. Но тоже обходимо.
Это я постарался привести рассуждения не особо философского характера, более менее прагматичные.
Re: Кому и зачем нужна Domain Model вместе с Hibernate
Здравствуйте, Аноним, Вы писали:
А>Если все можно сделать просто с помощью .NET и Table Model?
А>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?
А>Мне правда интересно
Может быть что нужна Domain model но не с Hibernate а например с IBatis,
это во многом зависит от того в какую сторону ведется разработка:
— если от обьектной модели, к БД, то Hibernate удобен
— если от БД к обьектной модели, то интеграция становится сложнее и
использование Hibernate будет затруднительным или вообще невозможным,
но Domain Model по прежнему будет существовать.
Re: Кому и зачем нужна Domain Model вместе с Hibernate
Здравствуйте, <Аноним>, Вы писали:
А>Если все можно сделать просто с помощью .NET и Table Model?
Table Model — это датасеты?
С помощью датасетов делается далеко не всё так просто. Если рассмотреть жизненный цикл некоторых данных, то чётко можно выделить три стадии:
1. DAL — чтение данных из БД.
2. BL — бизнес логика.
3. UI — отображение данных.
Датасеты совершенно чудным образом справляются с 1 и 3, но вот с 2 наблюдаются определённые проблемы (отдельный вопрос почему). Если сравнивать их с объектами, то нам понадобится вот такая картинка:
По горизонтали здесь приведены слои приложения. По вертикали некоторая величина, показывающая удобство использования того или иного средства. Чем выше, тем лучше.
Как было сказано выше, у датасетов с чтением их из базы и помещением на форму всё впорядке. Использовать их в бизнес логике получается очень громоздко и неудобно.
В противоположность датасетам для объектов (entities) совершенно отсутствуют стандартные средства чтения их из базы и отображения в UI. Зато с бизнес логикой нет никаких проблем.
ORM позволяют выровнять ситуацию с БД и поднять эту часть работы с объектами до уровня датасетов, а иногда и выше. Дополнительные средства вроде object-binding позволяют так же легко работать с объектами в UI как и с датасетами.
В результате мы имеем такую ситуацию. Если приложение требует наличия хоть какой-то маломальской бизнес логики, то связываться с датасетами уже не имеет никакого смысла. Если в приложение интенсивно используется бизнес логика, то датасеты — это путь в никуда.
И ответ на поставленный вопрос.
А>Если все можно сделать просто с помощью .NET и Table Model?
Если всё можно сделать просто, т.е. из приложения можно исключить слой бизнес логики, убрав тем самым слабое звено датасетов, и всё сводится к "прочитал из базы / положил на форму", то с датасетами не будет никаких проблем. Очень простое и доступное решение.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Кому и зачем нужна Domain Model вместе с Hibernate
Здравствуйте, IT, Вы писали:
IT>С помощью датасетов делается далеко не всё так просто. Если рассмотреть жизненный цикл некоторых данных, то чётко можно выделить три стадии:
IT>1. DAL — чтение данных из БД. IT>2. BL — бизнес логика. IT>3. UI — отображение данных.
IT>Датасеты совершенно чудным образом справляются с 1 и 3, но вот с 2 наблюдаются определённые проблемы (отдельный вопрос почему).
А что по поводу TypedDataset в NET 2.0 и возможности их расширения partial классами? (Это, конечно, очень специфично, но все же). Т.е. хотелось бы услышать, насколько это удобно по сравнению с ORM. Ведь с одной стороны имеем "совершенно чудным образом справляются с 1 и 3", а с другой — пиши любую функциональность в DataRow, иерархию классов можно заменить иерархией интерфейсов, тот же TableAdapter можно унаследовать от свего компонента и расширить в partial class. (Это не агитация за датасеты, просто интересно мнение по поводу...)
Re[3]: Кому и зачем нужна Domain Model вместе с Hibernate
Здравствуйте, Al_Shargorodsky, Вы писали:
A_S>А что по поводу TypedDataset в NET 2.0 и возможности их расширения partial классами? (Это, конечно, очень специфично, но все же). Т.е. хотелось бы услышать, насколько это удобно по сравнению с ORM. Ведь с одной стороны имеем "совершенно чудным образом справляются с 1 и 3", а с другой — пиши любую функциональность в DataRow, иерархию классов можно заменить иерархией интерфейсов, тот же TableAdapter можно унаследовать от свего компонента и расширить в partial class. (Это не агитация за датасеты, просто интересно мнение по поводу...)
partial classes — это большой шаг вперёд. Датасетами я сейчас не пользуюсь принципиально, т.к. в своё время у меня была ими передозировка и как результат была получена жестокая аллергия, но по идее partial classes должны решить часть проблем. Тем не менее, ещё остаются некоторые вопросы. Например, перечислители. В случае с объектами я могу использовать такой вариант:
public enum Gender
{
[MapValue("F")] Female,
[MapValue("M")] Male,
[MapValue("U")] Unknown,
[MapValue("O")] Other
}
и везде в приложении я буду работать с перечислителями. В случае с датасетами я буду вынужден использовать строковые константы.
Второй, более серьёзный момент — повторное использование сущностей. Одна и та же таблица, объявленная в разных датасетах — это два разнах класса. Соответственно написание одного общего бизнес кода для этих сущностей исключается.
Можно ещё повспоминать что-нибудь, но как я уже сказал, мне это малоинтересно. Для себя я уже давно решил проблемы как с отображением объектов в UI, так и с чтением их из базы, причем даже более высокоуровневыми средствами, чем предоставляет ADO.NET. В результате и код UI и код DAL получается значительно проще и короче. Поэтому, тема эффективного использования датасетов меня больше не волнует.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Кому и зачем нужна Domain Model вместе с Hibernate
Здравствуйте, achmed, Вы писали:
A> — если от БД к обьектной модели, то интеграция становится сложнее и A>использование Hibernate будет затруднительным или вообще невозможным, A>но Domain Model по прежнему будет существовать.
Обычно эксперты по С Шарпу должны задавать вопросы про Яву, а не утверждать веши, которые не верны.
Нибернейт предназначен для обоих путей проектирования.
Re[3]: Кому и зачем нужна Domain Model вместе с Hibernate
Dimonizhe wrote: > A> — если от БД к обьектной модели, то интеграция становится сложнее и > A>использование Hibernate будет затруднительным или вообще невозможным, > A>но Domain Model по прежнему будет существовать. > Обычно эксперты по С Шарпу должны задавать вопросы про Яву, а не > утверждать веши, которые не верны.
Поверь, я знаю проект над которым работает achmed — там Hibernate не
поможет. Слишком извращенная схема базы данных.
> Нибернейт предназначен для обоих путей проектирования.
Не всякая схема БД нормально на _разумную_ объектную модель ложится.