.NET Dataset vs Business Object: зачем спорить? Почему бы не объединить два?

Question

Я читаю дискуссию в комментариях здесь ( текущий живой сайт, без комментариев ).

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

И если мы должны, существует ли какая-либо легкая, всеобъемлющая структура, которая позволяет нам делать это (не тяжелый мамонт, как NHibernate, который имеет огромную кривую обучения)?

Answer 1

С "чистыми объектами" работать намного проще, типизированный объект дает вам проверку целостности и проверку типов во время компиляции.

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

Типизированные наборы данных - это шаг в правильном направлении, но «вещи», с которыми вы работаете в своем .NET-коде, все еще очень тесно и тесно связаны с реализацией вашей базы данных - как правило, не очень хорошая вещь, так как любое изменение в базовом коде база данных может повлиять на ваше приложение вплоть до вашего пользовательского интерфейса и привести к необходимости внесения множества изменений.

Использование ORM, такого как NHibernate, позволяет лучше абстрагировать и отделить уровень базы данных (физического хранилища) от вашей логической бизнес-модели - только в простейших сценариях эти два будут точно соответствовать 1: 1, поэтому вам потребуется какой-то "перевод" или сопоставление между ними в любом случае.

Таким образом, в целом - использование типизированных наборов данных может быть приемлемо для небольших простых приложений, но для сложного, масштабного бизнес-приложения корпоративного уровня я бы никогда не рекомендовал так тесно и тесно связывать вашу модель бизнес-объектов с базы данных.

Марк

Answer 2

Тед Ньюардс очень спорен, потому что мне кажется, что все пасут, как в старые времена EJB: никто не осмелился сказать, что EJB сосут, пока Род Джонсон не выйдет с Hibernate.

Теперь, кажется, никому нет дела до того, что ORM-фреймворки, такие как Hibernate, Entity Framework и т. Д., Слишком сложны, потому что, может быть, нет еще одного Рода Джонсона II:)

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

И на практике кажется, что слои, которые должны быть независимы, по крайней мере, с точки зрения графического интерфейса, на самом деле не являются. Я вижу, что многие люди изо всех сил пытаются делать простые вещи в GUI, когда они используют ORM.

Answer 3

Ну, все причины, которые вы приводите, были такими же, как академические причины, которые были приведены для EJB на Java, что в прошлом было неразберихой. Так разве люди не впадают в очередной модный обман?

Как я читаю здесь: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

обещание - это одно, а реальность - другое.

Где доказательства по претензиям?

С научной точки зрения, Сложность тесно связана с Концепцией Энтропии, вы не можете уменьшить внутреннюю сложность вещей, вы можете просто переместить ее в другое место, поэтому для меня есть нечто фундаментально ирациональное.

Answer 4

почему люди абсолютно хотят "чистую" модель объекта

Поскольку вы не хотите, чтобы ваше приложение зависело от схемы базы данных