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

Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

Мне правда интересно

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

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

А>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

А>Мне правда интересно

Ну.... .Нет лет на 10 моложе

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

OLE>Ну.... .Нет лет на 10 моложе

Не на 10, а на 5. .NET вышел в 2000году. А по существу?

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

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

OLE>>Ну.... .Нет лет на 10 моложе

А>Не на 10, а на 5. .NET вышел в 2000году. А по существу?

и Table Model тогда уже в нем был?

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

OLE>и Table Model тогда уже в нем был?

Ага. Книжка в сабже-то от 2002 года. Фаулер пользовался .NET уже в 2001 и на основании опыта использования хвалил Table Model

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

OLE>и Table Model тогда уже в нем был?

Или трудно книжку скачать? Она везде есть. Chapter 9

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

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

OLE>>и Table Model тогда уже в нем был?

А>Или трудно книжку скачать? Она везде есть. Chapter 9

Честно говоря неохота
И под линухом это все работает?

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

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

А>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

А>Мне правда интересно

Не очень понял. А бизнес логику тоже на таблицах писать? Это уже кто-то тут предлагал вместо объектов HashMap использовать.

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

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

А>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

А>Мне правда интересно

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

А>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

А Вы много этой книги Фаулера уже прочитали? Раздел Object-Relational Metadata Mapping Patterns читали ?
Про логику любой сложности на Table Model, насколько помнится он не писал, и через всю книгу красной нитью проходят высказывания типа: "для сложных приложений лучше использовать паттерн Domain Model", а в разделе Object-Relational Metadata Mapping Patterns
он перечисляте решения, с его точки зрения, лучше всего подходящие для Domain Model.

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

А>>Если все можно сделать просто с помощью .NET и Table Model?
А>>Читаю тут Patterns of Enterprise Application Architecture Фаулера и он прямо пишет, что в .NET реализованы прекрасные средства поддержки Record Setов и Table Model и логику любой сложности можно сделать использую только их. Тогда зачем морока с Hibernate и прочими O/R Mappings?

B>…А бизнес логику тоже на таблицах писать?

Это единственный недостаток?

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

B>>…А бизнес логику тоже на таблицах писать?

_FR>Это единственный недостаток?

А что этого не достаточно?

Тогда возникает встречный вопрос:
А зачем писать на .НЕТ (проектировать БД, создавать РекордСеты , увязывать их с гридами и деревьями и т.д.)?
Есть же 1С! там тоже логику любой сложности можно написать.
Зачем тогда мучится, минимизировать ошибки программирования и проектирования, оптимизировать запросы к БД?
Зачем?
Главное же — чтобы работало!

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

B>>>…А бизнес логику тоже на таблицах писать?
_FR>>Это единственный недостаток?

B>А что этого не достаточно?

А что, слабо? Шутка. В самом деле, ну какая разница, "достаточно" или нет, ведь это понятие "контекстно-зависимое" от того, "зачем". Предположим, интерес академический. Список составляю. Так всё же?

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


R>Главное же — чтобы работало!

Неправильный ответ .. Нужно брать ниже ) ...
Лично я утверждаю что логику [b]любой[b] сложности можно написать на ассемблере! Кто хочет возразить??? :D

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

AAV>Лично я утверждаю что логику [b]любой[b] сложности можно написать на ассемблере! Кто хочет возразить??? :D

Писать конечно можно, но придется вникать в технические детали (команды процессора, адресация памяти и т.д) .

Я имел ввиду написание "чистой" логики. — Здесь ассемблер не катит.

Razumyan wrote:
> AAV>Лично я утверждаю что логику [b]любой[b] сложности можно написать на
> ассемблере! Кто хочет возразить??? :D
> Писать конечно можно, но придется вникать в технические детали (команды
> процессора, адресация памяти и т.д) .
Ты сам сказал. Если писать прикладной код напрямую с БД, то придется
вникать в конкретные детали расстановки колонок, видов и т.п.

ORM позволяет писать код, работающий с абстрактными бизнес-объектами, не
заботясь о БД (до некоторой степени, конечно).

> Я имел ввиду написание "чистой" логики. — Здесь ассемблер не катит.
А почему не катит?

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

B>>>>…А бизнес логику тоже на таблицах писать?
_FR>>>Это единственный недостаток?

B>>А что этого не достаточно?

_FR>А что, слабо? Шутка. В самом деле, ну какая разница, "достаточно" или нет, ведь это понятие "контекстно-зависимое" от того, "зачем". Предположим, интерес академический. Список составляю. Так всё же?

Так просто из этого недостатка проистекают все остальные. Я просто не до конца представляю себе функциональность вышеназыванных классов чтобы точно указывать что можно имми реализовать а что нет.

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

>> Я имел ввиду написание "чистой" логики. — Здесь ассемблер не катит.
C>А почему не катит?

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

Oyster wrote:
>> > Я имел ввиду написание "чистой" логики. — Здесь ассемблер не катит.
> C>А почему не катит?
> Слишком тяжко писать будет. Для описания большого количества
> бизнес-правил в коде уровень абстракции должен быть повыше — иначе
> замучаешься думать низкоуровневыми категориями при описании довольно
> высокоуровневой логики. Есть для этого даже такие языки, как BPEL
> <http://en.wikipedia.org/wiki/Business_Process_Execution_Language&gt;,
> например — уровень абстракции выше некуда
Спасибо за дополнение к моему посту

Здравствуйте, 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 не
поможет. Слишком извращенная схема базы данных.

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