Как я могу создать веб-приложение Java без ORM и без встроенного SQL

Ответ 1

Почему, а почему индустрия так привязана к этой катастрофе концепции? Ни один из предыдущих ответов адекватно не учитывает проблемы @johnny. Все они являются полупродуманными оправданиями для размахивания рук, которые хорошо справляются с конкретными проблемами, стоящими перед программистами базы данных.

@TheTXI ответ типичен для ответов, которые я получаю, задавая один и тот же вопрос: разделение слоев. Что это должно значить? Почему я хочу отделить свои слои? Или, что более важно, как мне выгодно создать дополнительный слой, который отличается от реляционного уровня и все же должен быть каноническим отображением из этого слоя?

Кроме того, (@johhny пока еще без ответа), как это защитит нас от изменений? Если база данных изменится, уровень ORM почти наверняка последует примеру. Фактически, практика по умолчанию не моделирования таблиц объединения на уровне объекта делает это еще хуже, потому что, когда таблица неизбежно увеличивает некоторые дополнительные столбцы, вы не только добавляете дополнительные объекты в объектную модель, но также меняете ее топологию и силу куча кода переписать! Это катастрофа для управления изменениями и является классическим примером того, как ошибочный взгляд на отношения (думая, что они представляют объекты) судит катастрофу. Это просто не произошло бы, если бы вы просто сопоставили реляционную базу данных напрямую с конгруэнтными понятиями на языке программирования (подумайте о LINQ-to-SQL, а не LINQ-to-EF).

Самый большой неотвеченный вопрос в этом пространстве -— слон в комнате; является: какая проблема ORM предполагается решить? И не говорите "несоответствие объектно-реляционного импеданса". Это еще один размахивающий руками. Объясните, почему существует несоответствие импеданса, и почему это должна быть база данных, которая поступает на язык, а не на язык, идущий в базу данных. Мое объяснение заключается в том, что большинство языков программирования сосать при выражении и работе с реляционными данными, но это историческая реальность, которая начинает ускользать (LINQ-to-SQL был первым шагом ребенка в этом направлении), а не фундаментальный принцип на которой основывается звуковая архитектура.

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

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

РЕДАКТИРОВАТЬ: Спасибо @Крису за то, что уделили время комментарию. Это дает мне некоторые конкретные точки для решения... (Обратите внимание, что, хотя я часто обращаюсь к @Chris ниже, я не пытаюсь его конкретно назначить, его ответы типичны для комментариев, которые я все время слышу при обсуждении поэтому я надеюсь, что он не воспримет мою критику как личное оскорбление, они не предназначены для этого, и я искренне ценю время, которое он принял, чтобы ответить.)

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

• Я не защищаю исходный SQL в коде по всем очевидным причинам, а некоторые не столь очевидные (например, SQL не является ни алгеброй, ни исчислением, что делает функциональную декомпозицию практически невозможной).
• Я не сторонник монолитного дизайна приложения. Слои, в общем, хорошо.
• Я не сторонник загрязняющих объектных моделей с большим количеством линейных шумов, таких как специальные поля, методы и атрибуты. Честно говоря, это соломенный человек, поскольку модели домена/объекта существуют только в Вселенной ORM. Теперь я знаю, что LINQ-to-SQL имеет все эти классы с множеством шумных бит в них, но они просто за кадром; вы не редактируете этот код, и вы вообще не должны даже смотреть на него.

Теперь некоторые возражения против возражений:

• Утверждение о том, что приложения могут быть построены независимо от базы данных, необоснованно. По большому счету ORM - это всего лишь каноническое отображение на слой данных (таблицы Foo и Bar становятся классами Foo и Bar, а таблица FooBar становится своего рода жарким делом между классами Foo и Bar). В этом сопоставлении мало места для маневра, поэтому любое изменение модели данных почти наверняка потребует соответствующего изменения объектной модели. На мой взгляд, это хорошо, поскольку объект, который радикально отклонился от соответствующей модели базы данных, будет не более чем дополнительной головной болью обслуживания для всех заинтересованных сторон.
• Как только иллюзия, что ORM порождает независимость от модели данных, отбрасывается, все протесты о зле прямого взаимодействия с моделью данных становятся спорными. Но я хотел бы продолжить это немного дальше, чем просто уволить его. Связывание является важной особенностью проектирования системы. В какой-то момент должны быть приняты решения и предположения. Вы не можете запрограммировать все, используя одну таблицу "Вещи". Вы должны решить, что ваш домен содержит определенные конкретные понятия, а затем создает схемы и код, которые уважают эти концепции, рассматривают их как первоклассных граждан, жестко программируют их. Идея о том, что приложения должны быть независимыми от базы данных, ошибочна. База данных является (или должна быть) самым чистым представлением бизнес-знаний (я знаю, что это не всегда так, и я расскажу об этом позже). Связывание с этим представлением должно обеспечить самую сильную гарантию устойчивости, поскольку такая модель данных изменится только тогда, когда сам бизнес подвергнется некоторым внутренним изменениям. Короче говоря, связь с хорошо продуманной схемой базы данных - очень хорошая вещь.
• Слоизация не является самоцелью. Это хорошо, потому что он достигает определенной цели. Предыдущие пункты показывают, что расслоение между базой данных и приложением в том, как ORM не является ни эффективным, ни необходимым для достижения реальной цели устойчивости к изменениям. Это достигается благодаря хорошему дизайну базы данных.
• @Chris утверждает, что позволяя базе данных диктовать вещи stymies OO design. Это достаточно верно, но интересно, только если дизайн OO - лучший способ моделирования знаний. Почти полный отказ OODBMSs на рынке намекает, что это не так. Реляционная модель с ее предикат-логическим основанием обладает такой же выразительной способностью, как проектирование OO, не прибегая к теоретико-графическим сложностям моделей OO.
• @Крис возражает против реляционной модели на том основании, что она не решает сегодня проблемы (следовательно, движение NoSQL) полностью не соответствует значению. NoSQL означает "Нет SQL", а не "Нет реляционной модели". К сожалению, даже сторонники движения NoSQL, похоже, в этом отношении не совсем понятны. SQL имеет глубокие недостатки, многие из которых можно отследить до радикального отхода от реляционной модели. Сказать, что мы должны отказаться от реляционной модели, потому что SQL отстой - довольно вопиющий случай бросить ребенка с водой для ванн.
• Невозможность использования ORM не утроит усилий по созданию приложения. Это смехотворная претензия, и даже @Chris, похоже, держит заднюю дверь открытой на ней с отменным дополнением к альтернативе codegen. Инструменты Codegen, такие как LINQ-to-SQL sqlmetal, являются идеальным решением для всех, кто не согласен с догмой о том, что модель данных приложения абсолютно должна отличаться от модели данных базы данных.

Мой собственный опыт работы с ORM состоял в том, что они отлично работают в учебниках и вызывают бесконечную боль и разочарование в реальном мире. С LINQ-to-SQL, устраняющим многие проблемы, которые мотивировали ORM в первую очередь, я не вижу причин подвергать себя пыткам.

Остается одна серьезная проблема: текущая культура баз данных SQL не дает сколько-нибудь значимой степени контроля над разделением физических и логических уровней. Сопоставление таблицы с файлом на диске в значительной степени фиксировано и полностью находится под контролем СУБД SQL. Это не было частью плана реляционной модели, которая явно разделяла их и позволяла определять последовательное логическое представление данных, которые могли быть сохранены на диске в совершенно другой структуре, чем это было предложено логической моделью. Например, система (или dba) могла бы свободно физически денормализовать — по соображениям производительности; сильно нормированная логическая модель. Поскольку механизмы SQL не допускают такого разделения проблем, обычно денормализовать или иным образом пытать логическую модель с помощью чистой необходимости. В результате логические модели не всегда могут быть точно такими, какими они должны быть, поэтому идеал использования базы данных как самого чистого представления знания не может быть полностью реализован. На практике, однако, дизайнеры обычно придерживаются канонического сопоставления от базы данных до модели домена, так как все остальное просто слишком больно для поддержания.

Ответ 2

В моем опыте с NHibernate это немного похоже на Visual Basic: он делает легкие проблемы очень легкими, но также делает что-то более сложное, чем это действительно сложно или даже совершенно невозможно.

Основная идея заключается в том, что ORM избегает необходимости писать код настойчивости. В таком коде много дублирования, поэтому очень заманчиво сделать этот код общим, а не конкретным для определенного уровня бизнеса, и повторно использовать его в проектах. Все идет нормально. Для простых иерархий объектов и бизнес-требований это действительно работает очень хорошо. Если ваша база данных изменяется, да, вам нужно изменить файлы сопоставления ORM, но это обычно довольно просто, и вам нужно только внести изменения в одно место - гораздо проще, чем изменять код, который обращается к базе данных.

Проблема заключается в том, что по мере усложнения базы данных и требований ORM становится все труднее идти в ногу со временем. Таким образом, ORM становится все сложнее. Он также принимает быстрые клавиши, делая некоторые вещи неэффективно, потому что он просто недостаточно умен, чтобы понять, как сделать это эффективно во всех случаях. Что еще, потому что вся идея в том, что она работает прозрачно, вы часто не можете видеть эти проблемы с производительностью, пока они не станут достаточно плохими, чтобы повлиять на работу пользователя. Связанная с этим проблема заключается в том, что ошибки гораздо сложнее найти, потому что вы просто не знаете, что происходит внутри ORM, если вы не отлаживаете его. (Да, мне пришлось пройти через код NHibernate, и это не пикник!)

Итак, вы начинаете обходить ORM для некоторых вещей и вместо этого используете SQL. Конечно, вам нужно заставить этот код работать с кодом, который использует ORM, что больше работает. Вы в конечном итоге пишете код для загрузки и сохранения некоторых объектов вручную и для какой-то работы в коде ORM. В конце концов вы начинаете задаваться вопросом, создает ли ORM больше работы для вас, чем экономию - не говоря уже о головной боли производительности и ошибок.

Итак, если вы пишете очень простое приложение, которое вы найдете в учебнике, ORM сделает хорошую работу. Если это сложнее, чем тогда, я думаю, что это не стоит. Разумеется, для простого приложения абсолютное количество сохраненного времени также будет небольшим. Мой вывод: просто не беспокойтесь о ORM. ORM - это путь, ведущий к темной стороне.

Ответ 3

До того, как я прочитал это, я часто задавался вопросом, действительно ли кто-то действительно беспокоился о том, какое влияние оказывает инструмент ORM на проект. @Evgeny, @Marcelo Cantos и @Jimmy B положили это на отдых.

Короче говоря, они мертвы с большинством проблем, которые окружают инструменты ORM. Есть только пара, которую они либо не покрыли, либо недостаточно покрывали.

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

Во-вторых, инструменты ORM НЕ означают, что вам не нужно понимать SQL. Чтобы сказать об этом по-другому, вы должны знать, что SQL является эффективным программистом (есть исключения, такие как встроенные ребята). Запросы (оба типа и количества), испускаемые этими инструментами, просто недостаточно хороши с точки зрения производительности или ресурсов. Если вам уже нужно знать SQL, зачем сковывать себя?

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

В-четвертых, независимость СУБД обычно является пустой тратой времени. Большинство приложений будут использовать только одну СУБД над ней; будь то Oracle, SQL-сервер, MySql, что угодно. Приложение будет намного лучше, он сможет воспользоваться преимуществами, предоставляемыми СУБД. Будучи агностиком СУБД, вы должны ограничить себя дополнительными запросами.

В-пятых, не все должно быть объектом. Это важно отметить. Нам часто предлагается показать определенный набор данных на странице. Чаще всего это означает объединение данных из двух или более таблиц. Должно ли ваше приложение создавать и создавать экземпляры всех этих объектов только для отображения некоторых данных? Или вам лучше просто выполнить запрос и передать данные прямо на экран/браузер в выбранном вами формате?

ORM добавляет много накладных расходов даже на самые простые вещи. Большинство ORM генерируют несколько запросов sql для выполнения даже простого UPDATE в таблице.

В-шестых, и самая важная проблема в моем сознании: ORM снижает вашу безопасность. Конечно, вы можете использовать ORM с s'procs; но большинство людей этого не делает. Почти каждое приложение, которое я видел, использующее ORM, открыло базу данных таким образом, что если сайт взломан, вся база данных может быть легко убита или похищена. Инструменты ORM генерируют SQL "на лету". Это означает, что им нужен прямой доступ к таблице. Это означает, что если ваше приложение скомпрометировано, у хакера будет прямой доступ к таблице. Это означает, что вы удалили хотя бы один уровень безопасности из своего приложения.

Ответ 4

Я понимаю, что этот вопрос был опубликован некоторое время назад, но я задавался вопросом о том же, что и Джонни. Я видел, как Hibernate использовался на нескольких крупных проектах умными людьми, и в каждом случае это была беспрецедентная катастрофа. По моему опыту, самая сложная и влияющая на производительность область большинства корпоративных приложений - это уровень бизнес-уровня и уровня базы данных. Это часть того, почему мы добавляем уровень доступа к данным, чтобы попытаться инкапсулировать взаимодействие с базами данных в управляемые куски.

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

Чтобы сделать Hibernate (и большинство других инструментов ORM), мы либо создаем файл сопоставления спящего режима, который документирует все взаимодействия с базами данных и объектами, или мы используем аннотации для документирования тех же отношений. В одном случае мы переместили наш код в файл конфигурации xml, который сложнее проверить, но не менее сложный. В другом мы распространяем логику взаимодействия с базой данных по всей модели домена. Дело в том, что мы написали менее актуальный "код", перемещая код в файлы конфигурации или аннотации!= "Меньше кода". Он просто перемещает сложность с кода, где мы можем контролировать его напрямую и смягчать его, стороннему инструменту с гораздо меньшим контролем.

Уровень абстракции ORM, который должен отделить уровень бизнес-домена от уровня базы данных, имеет тенденцию к более тонким эффектам, которые противодействуют этому "разделению". Сколько проектов вы видели, когда уровень ORM влияет на дизайн объектной модели и/или базы данных таким образом, который считался бы менее идеальным? Чтобы использовать плохую физическую аналогию, предположим, что ваш бизнес-уровень, уровень ORM и уровень базы данных имеют массу. Простое существование слоя ORM между другим, как правило, приводит к силе, которая изменяется и искажает другие слои. Вам приходилось вводить первичный ключевой объект, который не совсем подходит для вашей бизнес-модели, потому что для него нужен слой ORM? Вам нужно было настроить структуру базы данных для размещения особенно сложной модели объекта, потому что инструмент ORM не может справиться с этим иначе? Взятый до крайности, наличие слоя ORM может исказить всю перспективу взаимодействия баз данных. Вместо уровня обслуживания, который обрабатывает сохраняющиеся графы объектов, он может превратиться в создание отдельных объектов уровня доступа к данным для каждого объекта домена, как если бы они жили изолированно. Я видел все эти сценарии в разной степени. Возможно, это неопытность с набором инструментов ORM. Возможно, это плохая структура базы данных. Я сомневаюсь в этом. Все, что я видел, указывает на то, что решение ORM является неадекватным.

Если вы согласитесь с моим утверждением о том, что уровень доступа к данным является сложным, сильно подверженным узким местам производительности, почему я должен рассмотреть возможность добавления в инструмент, который не достигает цели меньшего количества кода и разделения, и в то же время отрицательно влияя на структуру других слоев моего приложения?

Ответ 5

Я полностью ответил на ответ @Marcelo Cantos, однако я буду судить о главных преимуществах использования ORM.

Сохранение невосприимчивости (PI) и дизайн привода домена (DDD)

ORM отлично подходит для обоих этих шаблонов проектирования. Для правильного объектно-ориентированного проектирования вы будете работать с иерархическими и полиморфными объектами для выражения того, как потоки данных в вашем приложении. С хорошим дизайном вы часто будете стремиться к объектам POCO (простые старые объекты C/С#, я видел другие определения этого слова), потому что, если у меня есть Личность, у которой есть Список, я должен иметь именно это. Я не должен иметь DataTable для людей и DataTable адресов, которые я каким-то образом вынуждаю работать с моим приложением. Наряду с этим мне не нужно связывать тонны логики базы данных с моими объектами, почему для поля FirstName моего лица должно быть что-то вроде [ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)] или любого другого ассортимента сумасшедших атрибутов или кода, который определяет, сколько баз данных существует принудительно в моем дизайне домена?

Менее ручной письменный код

Существенное сокращение числа строк кода, написанных при удалении необходимости записи инструкции Select, Insert, Update и Delete для каждого отдельного объекта в приложении, чтобы сохранить его в базе данных. Это оставляет вам только необходимость писать запросы, которые что-то означают. Также многие ORM (например, NHibernate) будут включать язык, который накладывается поверх SQL, который более определен для взаимодействия и может быть менее синтаксически заполнен обручем.

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

Ответ 6

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

Разделение слоев обычно является целью приложений с 3 уровнями или n-уровнями, и ORM - хороший способ сделать это.

Ответ 7

Первичный драйвер: менее общий код для управления/поддержки

Ответ 8

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

Ive использовало 3 разных ORM (EF, LINQ to SQL и N-Hibernate), для проектов различных размеров от малых и крупных корпоративных приложений. Кроме того, Im не чужд обходить его с ADO.NET; DataReaders и сопоставление с классами, DataSets и различными инструментами генерации. Я видел хорошие и плохие реализации в трех разных ORM и без ORM-метода. Большинство проблем, которые я видел, возвращаются к анти-шаблонам и не понимают ограничений конкретного ОРМ. Следующая статья (Анти-Шаблоны, которые следует избегать в N-Tier Applications) делает хорошую работу, выделяя многие из этих Anti-Patterns. Даже лучшие разработчики программного обеспечения, разработчики и просто умные люди участвовали в своей акции Anti-Patterns, прежде чем они обнаружили шаблон дизайна и значение некоторых принципов проектирования, которые решили проблему, созданную Anti-Pattern.

Не зная, что ваш инструмент является еще одной проблемой, потому что именно здесь возникают проблемы с производительностью. Многие из них не уверены в различиях производительности между Dynamic SQL и хранимыми процедурами в отношении выполнения логики базы данных, такой как операции CRUD. Ну, вердикт, и динамические команды оказались столь же эффективными, как и их хранимые процедуры. Оба имеют свои преимущества и недостатки. Ключ знает, что это такое и выбирает подходящий выбор для ситуации.

Ответ 9

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

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

using (SqlWrapper sql = SqlWrapper.Create(WrapperConnectionType.ShopNet, "sStore_InsertUpdate_v4"))
            {
                sql.AddParameter("StoreId", StoreId);
                sql.AddParameter("StoreName", StoreName);
                sql.AddParameter("Region", Region);
                sql.AddParameter("PostCode", PostCode);
                sql.AddParameter("Tel", Tel);
                sql.AddParameter("Email", Email);
                sql.AddParameter("RegionId", RegionId);
                sql.AddParameter("MapImage", MapImage);
                sql.AddParameter("ShopImage", ShopImage);
                sql.AddParameter("Visible", Visible ? 'Y' : 'N');
                sql.AddParameter("TazEnabled", TasEnabled ? 'Y' : 'N');
                sql.AddParameter("Latitude", Latitude);
                sql.AddParameter("Longitude", Longitude);
                sql.AddParameter("StoreOpeningDate", OpeningDate);
                sql.AddParameter("CustomerNo", CustomerNo);
                sql.AddParameter("ReserveAtStoreEnabled", RasEnabled);
                sql.AddParameter("OpeningHoursId", OpeningHours.Id);
                sql.AddParameter("AddressLine1", AddressLine1);
                sql.AddParameter("AddressLine2", AddressLine2);
                sql.AddParameter("City", City);
                sql.AddParameter("District", District);
                sql.AddParameter("County", County);
                sql.AddParameter("CountryCode", CountryCode);
                sql.AddParameter("GoogleCategories", GoogleCategories);
                sql.AddParameter("GooglePlacesEnabled", GooglePlacesEnabled);
                sql.AddParameter("ManagerName", ManagerName);
                sql.AddParameter("MapZoomLevel", MapZoomLevel);
                sql.AddParameter("IpAddress", IpAddress);
                sql.AddParameter("FlibbleEnabled", FlibbleEnabled);
                sql.AddParameter("RegionalManager", RegionalManagerId);
                sql.AddParameter("ShutlLogin", ShutlLogin);
                sql.AddParameter("ShutlPassword", ShutlPassword);
                sql.Execute();
            }

и позволяет искоренить (но не забывать) следующие типы сражений:

System.IndexOutOfRangeException
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)

Аргумент для меня не должен быть более сложным, я получаю пару приятных вещей, и что-то ужасное уходит. Нафф сказал: "Далее!

Никто не утверждает, что ORM - это 100% замена для всего традиционного. Это не будет отличным инструментом для написания сложных отчетов, для использования SP и представлений, а также с помощью NHibernate, чтобы вызвать их изначально и автоматически сопоставить их с вашими объектами С#. Отличная, по-прежнему полная сила SQL и отсутствие дурного кода сопоставления.

Пойдите во тьму, которую вы храните в 0s и 1s, и придите сюда, чтобы начать здоровое С# weltanschauung.

Ответ 10

1 вы получаете то, что ваш уровень данных отделен от слоя объекта, поэтому, когда у вас есть несколько приложений/проектов, зависящих от этого уровня, вы один раз меняете его в ORM и во всех приложениях/проектах, которые ссылаются на слой объекта, t должен измениться, где без него вам придется внести изменения во все проекты.