Так ли это???

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

у кого есть какие мнения?

Пока я, читая всякие статьи и постинги в разных местах нашел немного пищи для размышлений по этой теме:
Общие замечания:
1) все зависит от ситуации - самый точный и самый распространенный, в смысле безошибочный ответ, действительно причин может быть масса от привычек разработчика или идеологии в рамках команды до "по результатам тестирования". Толку от такого ответа мало.
2) объектно-реляционная тема имеет глубокие исторические корни, есть адепты как с объектной стороны (CSLA Лотки), так и с другой (вот этот товарищ из статьи, впрочем, не самый яркий). Я, например, не отягощенный особенно предыдущим опытом разработки, оказался посредине.
3) в данном случае выбор между Датасет и библиотекой классов - это выбор идеологии разработки. Обе идеологии позволяют, на мой взгляд, получить одинаковые результаты на выходе, но рефакторинг одного в другое - все равно что делать заново.
4) оценку целесообразно вести в рамках трех- и более звенной архитектуры, с наличием DAL, помня, что в дотнет извлекать данные из реляционной БД можно либо через DataAdapter, либо через DataReader
Собственно пища, то есть то, что меня путает немного:
а) Есть мнение, что Датасет более более пригодна для мелких проектов, реализация проекта с использованием Датасет, как центрального элемента архитектуры, так например, как сделано в Duwamish 7.0, не позволяет в полной мере реализовать сложную бизнес-логику
б) Быстродействие при использовании Датасет ниже - суждение, как мне кажется, не уровня архитектуры в целом
в) Разработка при использовании Датасет проще и занимает меньше времени
г) Распределенные приложения, сериализация - особая тема, реализуемо и объектной архитектуре и с использованием DataSet, к сожалению не могу понять преимуществ - нет серьезного опыта, чтобы сравнить.
д) я не видел еще, кроме упомянутых микрософтовских и самых примитивных, примеров, где ADO.NET активно используется именно для этих целей. Зато есть примеры построения DAL с использованием Reflection, классы и коллекции "наполняются" из базы данных, ADO.NET используется только для этой цели (Rsdn.Framework.Data, есть и другие). Там иногда (зачем?) даются оговорки, в том смысле, что вроде библиотека классов уже есть, и потому так бывает нужно. Почему?
е) stateless и statefull применительно к универсальности платформы и возможности разработки общей логики для различных интерфейсов. Тут у меня тоже нет опыта, чтобы судить очень подробно, хотелось бы услышать чье-то мнение.
ж) ADO.NET и XML очень переплетены. На мой взгляд, представление объектов в XML - вектор, давний вектор, развития ОО подходов особенно в программировании распределнных систем и в развитии баз данных тоже. То есть, если говорить объект-XML, то и проблем вроде как меньше, чем когда говоришь объект-DataSet. Понятно, о чем я хотел сказать?

Вообщем вопросы о недостатках DataSet по сравнению с библиотекой классов. Что бы такое нельзя сделать средствами ADO.NET, что можно, используя классы. Вот это хотелось бы обсудить.

что все молчат?

Эдвард МакЛинн
Из книги "К. Г. Юнг"
С психиатрической точки зрения Юнг разговаривал сам с собой, и весь этот опыт является примером шизофрении, психотическими симптомами

я тут подумал еще, что через призму Framework, typed DataSet тоже иерархия классов, с коллекциями, методами и свойствами. То есть ее вполне можно модифицировать под свои задачи, перенеся какие-то Business Rules "внутрь". Отсюда по меньшей мере один поверхностный, внеархитектурный, но абслютный вывод - DataSet всегда медленнее, как ни крути! Так что пункт б) имеет право на жизнь.

Андрей Платонов ...Вощев согласен был и не иметь смысла существования, но желал хотя бы наблюдать его в веществе тела другого, ближнего человека...

вот еще информация о System.Data.ObjectSpaces, по поднятой теме: Overview of the ObjectSpaces Architecture

там же ... и сердце обратило внимание на жар жизни вокруг костра классовой борьбы и произошел бы энтузиазм!

о как, по теме :)

туда же, до кучи
PDC - .NET Framework: Developing Applications using the New Object-Relational Technologies in "Whidbey" - ADO.NET ObjectSpaces

пожалуйста,

2 Dronopotamus
погибнуть не погибнешь, конечно. Просто позиция в один момент сама появится :)

Андрей ПлатоновИнженер Прушевский уже с двадцати пяти лет почувствовал стеснение своего сознания и конец дальнейшему понятию жизни, будто темная стена предстала в упор перед его ощущающим умом. И с тех пор он мучился, шевелясь у своей стены, и успокаивался, что, в сущности , самое срединное, истинное устройство вещества, из которого скомбинирован мир и люди, им постигнуто, - вся насущная наука расположена еще до стены его сознания, а за стеною находится лишь скучное место, куда можно и не стремиться. Но все же интересно было -- не вылез ли кто-нибудь за стену вперед.

а если объект из BL, по твоему или по ихнему, передается в DAL на сохранение, он что становится BE только на время своего пути? Сущность она и есть сущность в концептуальной модели, она часть предметной области, далее уже это именованный класс, с поведением и свойствами, он же может писать что угодно, он может вообще что-то захотел сказать такое, что раньше никто не говорил, и поэтому неясно выразился :)
Ты вряд ли захочешь, проектируя приложение, описывать одну и ту же сущность дважды, один раз - чтобы сущность была объектом класса, а второй раз - чтобы передать ее между слоями. ADO.NET, а именно DataSet универсальна, позволяет сделать BL относительно просто, "отсоединенность" же делает такую архитектуру очень похожей на иерархию классов со свойствами-коллекциями. Это первая причина недопонимания. Вторая причина, то что намереваются исправлять в будущем (ObjectSpaces и Yukon), то что ADO.NET место стыковки с объектной архитектурой осталась как бы со старых времен, вернее новые времена еще не наступили, что само по себе результат неожиданный, это на фоне то всех инноваций. И получается, нужен как бы отдельный слой для объектов ADO.NET, и это при том, что Dataset, DataTable можно вывести напрямую к UI, не заморачиваясь с написанием классов и пр. Третья причина - столь широкий выбор при недостатке информации или ее неперивариваемом избытке, как угодно, делает выбор сложнее, а не проще.