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

C>Спасибо за дополнение к моему посту

Да... плохо прочитал

Здравствуйте, Аноним, Вы писали:

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-контейнерам. Но тоже обходимо.

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

Здравствуйте, Аноним, Вы писали:

А>Если все можно сделать просто с помощью .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 по прежнему будет существовать.

Здравствуйте, <Аноним>, Вы писали:

А>Если все можно сделать просто с помощью .NET и Table Model?

Table Model — это датасеты?

С помощью датасетов делается далеко не всё так просто. Если рассмотреть жизненный цикл некоторых данных, то чётко можно выделить три стадии:

1. DAL — чтение данных из БД.
2. BL — бизнес логика.
3. UI — отображение данных.

Датасеты совершенно чудным образом справляются с 1 и 3, но вот с 2 наблюдаются определённые проблемы (отдельный вопрос почему). Если сравнивать их с объектами, то нам понадобится вот такая картинка:



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

Как было сказано выше, у датасетов с чтением их из базы и помещением на форму всё впорядке. Использовать их в бизнес логике получается очень громоздко и неудобно.

В противоположность датасетам для объектов (entities) совершенно отсутствуют стандартные средства чтения их из базы и отображения в UI. Зато с бизнес логикой нет никаких проблем.

ORM позволяют выровнять ситуацию с БД и поднять эту часть работы с объектами до уровня датасетов, а иногда и выше. Дополнительные средства вроде object-binding позволяют так же легко работать с объектами в UI как и с датасетами.

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

И ответ на поставленный вопрос.

А>Если все можно сделать просто с помощью .NET и Table Model?

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

Здравствуйте, 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. (Это не агитация за датасеты, просто интересно мнение по поводу...)

Здравствуйте, 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 получается значительно проще и короче. Поэтому, тема эффективного использования датасетов меня больше не волнует.

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

A> — если от БД к обьектной модели, то интеграция становится сложнее и
A>использование Hibernate будет затруднительным или вообще невозможным,
A>но Domain Model по прежнему будет существовать.

Обычно эксперты по С Шарпу должны задавать вопросы про Яву, а не утверждать веши, которые не верны.

Нибернейт предназначен для обоих путей проектирования.

Dimonizhe wrote:
> A> — если от БД к обьектной модели, то интеграция становится сложнее и
> A>использование Hibernate будет затруднительным или вообще невозможным,
> A>но Domain Model по прежнему будет существовать.
> Обычно эксперты по С Шарпу должны задавать вопросы про Яву, а не
> утверждать веши, которые не верны.
Поверь, я знаю проект над которым работает achmed — там Hibernate не
поможет. Слишком извращенная схема базы данных.

> Нибернейт предназначен для обоих путей проектирования.
Не всякая схема БД нормально на _разумную_ объектную модель ложится.