Зачем нам нужны объекты сущностей? [закрыто]

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

Я не уверен, что объекты сущностей должны существовать.

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

Моя текущая философия дизайна такова:

  • Весь доступ к базе данных должен осуществляться через хранимые процедуры.
  • Всякий раз, когда вам нужны данные, вызывайте хранимую процедуру и перебирайте SqlDataReader или строки в DataTable.

(Примечание: я также создавал корпоративные приложения с Java EE, java, ребята, замените эквивалент на мои .NET примеры)

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

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

Я использовал OR Mappers. Я написал несколько. Я использовал стек Java EE, CSLA и несколько других эквивалентов. Я не только использовал их, но и активно разрабатывал и поддерживал эти приложения в производственных средах.

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

Рассмотрим этот простой пример: вы получаете звонок в службу поддержки по поводу определенной страницы в вашем приложении, которая работает неправильно, возможно, одно из полей не сохраняется, как должно быть. С моей моделью разработчик, которому поручено найти проблему, открывает ровно 3 файла . ASPX, ASPX.CS и файл SQL с хранимой процедурой. Проблема, которая может быть отсутствующим параметром при вызове хранимой процедуры, занимает несколько минут. Но с любой моделью сущностей вы неизменно запустите отладчик, начнете пошагово выполнять код, и у вас может получиться 15-20 файлов, открытых в Visual Studio. К тому времени, когда вы спуститесь на дно стека, вы забыли, с чего начали. Мы можем хранить столько вещей в наших головах одновременно. Программное обеспечение невероятно сложное без добавления ненужных слоев.

Сложность разработки и устранение неполадок - это только одна из сторон моего понимания.

Теперь поговорим о масштабируемости.

Понимают ли разработчики, что каждый раз, когда они пишут или изменяют какой-либо код, взаимодействующий с базой данных, им необходимо провести тщательный анализ точного воздействия на базу данных? И не только копия для разработки, я имею в виду имитацию производства, поэтому вы можете видеть, что дополнительный столбец, который вам сейчас нужен для вашего объекта, только что сделал недействительным текущий план запроса, а отчет, который выполнялся за 1 секунду, теперь займет 2 минуты, просто потому что вы добавили один столбец в список выбора? И получается, что индекс, который вам сейчас нужен, настолько велик, что администратору БД придется изменить физическую структуру ваших файлов?

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

Я не фанатик. Я могу быть уверен, что ошибаюсь, а может, и так, потому что есть такой сильный толчок в направлении Linq к Sql, ADO.NET EF, Hibernate, Java EE и т. Д. Пожалуйста, продумайте свои ответы, если я что-то упускаю очень хочу знать, что это такое и почему я должен изменить свое мышление.

[Редактировать]

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

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

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

Спросите кого-нибудь, кто давно работает в отрасли и работал с долгоживущими приложениями: сколько уровней приложений и пользовательского интерфейса появилось и ушло, пока база данных дожила? Насколько сложно настроить и реорганизовать базу данных, когда есть 4 или 5 разных уровней персистентности, генерирующих SQL для получения данных? Вы не можете ничего изменить! ORM или любой код, который генерирует SQL, блокирует вашу базу данных в камне .

20.08.2008 19:37:53
Прочитав ваш вопрос, мы очень похожи, и я удивляюсь тому же самому в течение многих лет (с тех пор, как услышал о сторонних структурах сущностей, а теперь и Microsoft)
pearcewg 3.03.2009 17:23:51
Вы говорите, что бизнес-логика является вспомогательными объектами или в хранимых процессах? Я спрашиваю, как многие думают, что вы говорите позже ... но я думаю, что вы говорите, что у вас все еще есть бизнес-логика в закодированных объектах, вы просто получаете данные прямо из базы данных и используете эти данные вместо ORM или сопоставления со специализированными объектами для хранения данных. Я склонен чувствовать то же самое - но в настоящее время я также оцениваю EF4, чтобы понять, стоит ли оно того.
alchemical 14.06.2010 18:32:10
«Потребители-новаторы часто оказываются в замешательстве». - кто-то с опытом
Uğur Gümüşhan 11.09.2012 13:29:28
Я унаследовал систему с более чем 2500 SPROC, где приложение рассматривается просто как средство активации SPROC и понимания их вывода. Каждое чтение и запись данных имеет свой собственный SPROC. Здесь нет центральных точек контроля. Это отвратительно и примерно так же податливо, как гранит. Я считаю, оптимизация баз данных. 2500 SPROCS поставили меня на мое место. По сравнению с системой с хорошо организованным доменным уровнем и многократно используемым кодом DAL она выглядит непродуманной и является кошмаром поддержки. Простые задачи занимают часы и разрушают душу. SPROC должны использоваться для высоких нагрузок или специальных методов IMO
trucker_jim 19.05.2014 15:29:19
О вашем примере «отладки»: с помощью модульных тестов вы гораздо быстрее узнаете, где что-то не так.
MarioDS 15.12.2016 08:36:13
30 ОТВЕТОВ

Одна из причин - отделение модели вашего домена от модели базы данных.

Я использую Test Driven Development, поэтому сначала пишу свои слои UI и Model, а слой Data моделируется, поэтому UI и модель строятся вокруг объектов, специфичных для предметной области, а затем я сопоставляю эти объекты с любой технологией, которую я использую Уровень данных. Плохая идея позволить структуре базы данных определять дизайн вашего приложения. По возможности, сначала напишите приложение, и пусть это повлияет на структуру вашей базы данных, а не наоборот.

25
1.04.2009 15:06:16
Я должен сказать, что я действительно не согласен, по крайней мере, для корпоративных приложений. Данные приложения.
Eric Z Beard 12.09.2008 02:54:59
почему вы хотите иметь две отдельные модели с одинаковыми данными?
Seun Osewa 7.12.2008 22:45:31
Потому что для некоторых целей одна интерпретация модели может быть более подходящей. Некоторая логика работает намного лучше на объектах, чем на строках.
Wouter Lievens 23.12.2008 15:01:14
Я думаю, что это хорошая идея, реализованная плохо.
Jeff Davis 14.07.2009 16:36:17

Я нашел ваш вопрос действительно интересным.
Обычно мне нужны объекты сущностей для инкапсуляции бизнес-логики приложения. Было бы очень сложно и неадекватно внедрить эту логику в уровень данных.
Что бы вы сделали, чтобы избежать этих объектов сущностей? Какое решение вы имеете в виду?

4
20.08.2008 20:44:15
Это было бы лучше в качестве комментария
Casebash 9.07.2010 01:49:19

@ Дэн, извини, это не та вещь, которую я ищу. Я знаю теорию. Ваше утверждение «очень плохая идея» не подкреплено реальным примером. Мы пытаемся разрабатывать программное обеспечение за меньшее время, с меньшим количеством людей, с меньшим количеством ошибок, и мы хотим иметь возможность легко вносить изменения. Ваша многослойная модель, по моему опыту, является негативной во всех вышеперечисленных категориях. Особенно в отношении того, чтобы сделать модель данных последним, что вы делаете. Физическая модель данных должна быть важным фактором с первого дня.

7
20.08.2008 20:46:59
вау, кто-то еще, кто думает как я об этом ... мои приложения почти всегда касаются манипулирования данными, именно это они и делают.
alchemical 14.06.2010 18:10:38
Это было бы лучше в качестве комментария теперь, когда эти функции доступны
Casebash 9.07.2010 01:48:39
Простите, что я педантичен, но так как это популярный вопрос, а ошибка, которую вы совершили, является распространенной, я почувствовал, что должен указать на это. «Меньше времени» - это правильно, но «меньше людей» и «меньше ошибок» должны быть «меньше людей» и «меньше ошибок». Если у вас меньше муки, вы можете сделать меньше печенья. (Кроме того, если вы используете слишком много муки, вы будете делать слишком много печенья - различие, которое часто забывают.) Опять же, мои извинения; просто пытаюсь быть полезным.
WCWedin 28.01.2011 18:29:55

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

3
23.05.2017 12:01:28

@jdecuyper, одна из тем, которую я часто повторяю себе: «если вашей бизнес-логики нет в вашей базе данных, это всего лишь рекомендация». Я думаю, что Пол Нильсон сказал это в одной из своих книг. Прикладные уровни и пользовательский интерфейс приходят и уходят, но данные обычно живут очень долго.

Как мне избежать объектов сущности? Хранимые процедуры в основном. Я также свободно признаю, что бизнес-логика стремится охватить все уровни приложения независимо от того, намерены вы это делать или нет. Определенная степень сцепления является неотъемлемой и неизбежной.

2
20.08.2008 20:54:15
Я согласен, что бизнес-логика, которая присутствует в приложении, часто не учитывает другие способы ввода, удаления или изменения данных. Это обычно вызывает проблемы целостности данных в дороге.
HLGEM 3.12.2008 19:17:28
И почему вы всегда должны использовать сервисный уровень для обработки несоответствия между объектным миром и миром отношений. Перетекание бизнес-логики на каждый уровень, безусловно, НЕ неизбежно.
cdaq 14.05.2013 19:58:44

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

Итак, я бы сказал, что нет единого ответа на все вопросы. Разработчики должны знать, что иногда попытка быть слишком ОО может вызвать больше проблем, чем решает.

59
10.12.2008 09:07:56
Кристофер, похоже, ты воскресил этот вопрос, связавшись с ним другим вопросом. Мне интересно, что вы подразумеваете под "богатыми взаимодействиями", и как было бы нецелесообразно реализовывать их без объектов?
Eric Z Beard 12.09.2008 02:57:30
Все, что может быть сделано с объектами, также может быть сделано без объектов. Я считаю, что ОО-дизайн обычно намного проще, чем не-ОО-методы, делать что-то «сложное», но я понимаю, что он не работает для всех.
Kristopher Johnson 12.09.2008 10:32:21
Я согласен - ответ «когда использовать объекты» зависит от того, могут ли свойства объектов требовать действий или изменений в бизнес-логике. Например, экземпляры User или Person могут иметь Password и LoginName -> ваши действия кода изменяются в зависимости от значений в них. Напротив, если бы у вас был Продукт, вы бы сделали отображение (ничего более, никаких других действий), чем получили бы DataSet из db и просто построили GUI.
Yordan Georgiev 18.04.2009 08:20:07
Есть баланс. Избегайте религии и выбирайте то, что работает.
Jeff Davis 17.06.2010 13:24:58

Я думаю, что вы просто привыкли писать конкретные заявки и решать определенные проблемы. Вы, кажется, атакуете это с точки зрения «базы данных в первую очередь». Есть много разработчиков, где данные сохраняются в БД, но производительность не является главным приоритетом. Во многих случаях размещение абстракции над уровнем персистентности значительно упрощает код, и затраты производительности не являются проблемой.

Что бы вы ни делали, это не ООП. Это не неправильно, это просто не ООП, и нет смысла применять ваши решения к каждой другой проблеме.

0
20.08.2008 21:03:20
Данные всегда на первом месте. Это причина, по которой у вас есть компьютерная программа. Таким образом, «база данных сначала», возможно, является единственным подходящим подходом для разработки приложений.
gbjbaanb 15.11.2008 15:54:47

Теория говорит, что очень связные, слабо связанные реализации - это путь вперед.

Поэтому я полагаю, что вы ставите под сомнение этот подход, а именно разделение интересов.

Должен ли мой файл aspx.cs взаимодействовать с базой данных, вызывать sproc и понимать IDataReader?

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

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

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

Кроме того, кажется, что ваш подход защищает бизнес-логику вашего приложения в вашей базе данных? Мне кажется, что это неправильно, SQL действительно хорош для запросов данных, а не, imho, для выражения бизнес-логики.

Интересная мысль, хотя, хотя он чувствует себя в шаге от SQL в aspx, который из моих плохих старых неструктурированных дней asp наполняет меня страхом.

27
20.08.2008 21:09:06
Я согласен с тем, что большое количество динамического SQL, разбросанного по всему коду, является злом. Вы должны держать Db звонки ясными и четкими. Обертывание вызовов sproc в статических вспомогательных методах обеспечивает своего рода разделение, не проходя весь путь ORM.
Eric Z Beard 12.09.2008 03:01:19
Хотя я никогда не работал в среде asp, я уверен, что некоторые из менее технических людей взорвут ваши носки с помощью некоторого клиентского javascript-кода, что приведет к прекрасному взаимодействию с пользователем независимо от какого-либо дрянного интерфейса технической поддержки. -конец.
crowne 9.02.2010 09:24:23
Я согласен с вами здесь, и мне известно, что я также создал некоторый javascript на стороне клиента, что привело к не слишком плохому взаимодействию с пользователем, даже если я сам так говорю. Я хотел бы думать, что внутренние интерфейсы не являются дрянными, и что любые программисты на стороне клиента не должны беспокоиться об этом, потому что я пытался отделить свои проблемы.
nachojammers 9.02.2010 17:12:54
«Мне кажется, это неправильно, SQL действительно хорош для запроса данных, а не для имхо, выражая бизнес-логику». - Если вы не используете, скажем, PL / SQL, который добавляет богатый язык программирования поверх (и тесно интегрирован с) SQL, и ваш код хранится в базе данных. Повышает производительность, избегая сетевых обращений. И инкапсулирует вашу бизнес-логику независимо от того, какой клиент подключается к базе данных.
ObiWanKenobi 15.12.2010 14:27:11

Что делать, если вам нужно масштабировать ваше приложение путем балансировки нагрузки более чем на одном веб-сервере? Вы можете установить полное приложение на все веб-серверы, но лучшим решением будет заставить веб-серверы взаимодействовать с сервером приложений.

Но если нет никаких объектов сущностей, им не о чем будет много говорить.

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

Это экономит время, когда дело доходит до его поддержания.

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

3
20.08.2008 21:04:41
Многие люди поднимают связь и позволяют одному слою меняться, не влияя на другой. Хранимые процедуры делают это лучше, чем любой ORM! Я могу радикально изменить модель данных, и пока процедуры возвращают одни и те же данные, ничто не нарушается.
Eric Z Beard 12.09.2008 03:03:24
По моему мнению, хранимые процедуры И модель сущностей не являются взаимоисключающими. Хранимые процедуры могут предоставить механизм для хранения вашей модели сущностей. Вопрос в том, работает ли ваша бизнес-логика с сущностями или имеет доступ к хранимым процедурам напрямую?
jbandi 5.11.2008 09:46:39

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

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

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

Я также склонен думать, что при надлежащем модульном тестировании на ранних этапах этот сценарий, например, что отсутствие одного столбца, скорее всего, не будет проблемой.

21
20.08.2008 21:13:39
«ваше приложение - это не ваши данные, данные - это артефакт приложения». - Приложение бесполезно без данных. Данные имеют большое значение без приложения. Приложения приходят и уходят (переписываются) постоянно, данные в любом нетривиальном приложении всегда сохраняются. И модель данных остается на удивление стабильной во времени.
ObiWanKenobi 15.12.2010 14:32:51

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

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

Например, идея «клиента» может состоять из основной записи в таблице «Клиент», объединенной со всеми заказами, которые разместил клиент, а также со всеми сотрудниками клиента и их контактной информацией, а также с некоторыми свойствами клиент и его дети могут быть определены из справочных таблиц. С точки зрения разработки действительно приятно иметь возможность работать с Заказчиком как с единым целым, так как с точки зрения бизнеса концепция Заказчика содержит все эти вещи, и отношения могут быть или не быть реализованы в базе данных.

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

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

2
20.08.2008 21:18:19

Я хотел бы ответить примером, подобным тому, который вы предложили.

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

Что (на мой взгляд) субъекты привносят в проект:

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

Тестируемость: вы можете проверить свою логику, не касаясь базы данных. Это повышает производительность ваших тестов (позволяя вам запускать их чаще).

Разделение проблем: В большом продукте вы можете назначить базу данных для администратора баз данных, и он может чертовски оптимизировать его. Назначьте модель бизнес-эксперту, который обладает знаниями, необходимыми для ее разработки. Назначать разработчикам более опытные формы веб-форм и т. Д.

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

Приветствия.

10
20.08.2008 21:25:25
Хранимые процедуры, вероятно, являются лучшим примером ортогональности и разделения проблем. При правильном использовании они полностью инкапсулируют базу данных.
Eric Z Beard 12.09.2008 03:04:34
@Eric Z Beard: Да, но как вы можете написать модульные тесты для хранимых процедур, изолируя только логику внутри хранимой процедуры? Хранимые процедуры тесно связаны с базой данных, и большинству из нас типы ORM не нравятся. Чтобы написать модульный тест для хранимой процедуры, вам нужно полагаться на определенные данные, которые будут находиться в базе данных. и вы не можете перезапускать этот тест снова и снова без этой зависимости от данных. Этот тест, который вы напишете, больше не будет модульным тестом, а будет интеграционным тестом.
7wp 30.10.2009 17:40:01

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

  1. Как бы вы провели модульное тестирование, если бы вся ваша бизнес-логика была в вашей базе данных?
  2. Разве изменения в вашей базе данных, особенно те, которые затрагивают несколько страниц в вашем приложении, не станут главной проблемой для приложения?
0
20.08.2008 21:26:43

Эрик, ты мертв. Для любого действительно масштабируемого / легко обслуживаемого / надежного приложения единственный реальный ответ - обойтись без всего мусора и придерживаться основ.

Я следовал сходной траектории с моей карьерой и пришел к тем же выводам. Конечно, нас считали еретиками и смотрели на смешных. Но мои вещи работают и работают хорошо.

Каждая строка кода должна рассматриваться с подозрением.

16
22.08.2008 04:49:15
конечно, это действительно хорошо работает, когда у вас есть тонны персонала и ресурсов, но я думаю, что если вы команда из одного человека, подумайте, что «новые» методы могут очень помочь ..
Carl Hörberg 4.08.2009 15:03:57

Объекты Entity могут облегчить кэширование на прикладном уровне. Удачи в кэшировании данных.

4
22.08.2008 04:51:23

Хороший вопрос!

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

Например,

Объект AnswerIterator генерирует объекты AnswerIterator.Answer. Под капотом он перебирает оператор SQL, чтобы получить все ответы, и другой оператор SQL, чтобы получить все связанные комментарии. Но при использовании итератора я просто использую объект Answer, который имеет минимальные свойства для этого контекста. С небольшим количеством скелетного кода это становится почти тривиальным.

Я обнаружил, что это хорошо работает, когда у меня есть огромный набор данных для работы, и когда все сделано правильно, он дает мне небольшие переходные объекты, которые относительно легко проверить.

По сути, это тонкий шрифт над компонентом доступа к базе данных, но он все еще дает мне возможность абстрагировать его, когда мне это нужно.

0
12.09.2008 02:36:47

Эрик,

Никто не мешает вам выбрать ту структуру / подход, который вы пожелаете. Если вы собираетесь пойти по пути «управляемые данными / хранимые процедуры», то обязательно сделайте это! Особенно, если это действительно, действительно помогает вам доставить ваши приложения в срок и в срок.

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

При этом применяются те же правила, если вы подаете заявку в ООП: будьте последовательны. Постулаты Следуйте ООП, и что включает в себя создание сущности объектов для представления ваших моделей предметной области.

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

2
12.09.2008 02:45:15
Я согласен с последовательностью во всем приложении. Честно говоря, я изменил направление моего текущего проекта некоторое время назад и не удосужился исправить 100% оригинальной модели, что приводит к путанице. Хорошие решения лучше всего принимать рано.
Eric Z Beard 12.09.2008 03:26:40
Эрик, правда. Когда-то я был фанатом ООП (как, кажется, и другие в этой теме), но я встретил парня, который владеет компанией, которая очень успешно продает приложения, управляемые БД. Это потрясло мой мир. Я по-прежнему любитель ООП / ТДД, но я больше не осуждаю DB-ориентированность.
Jon Limjap 12.09.2008 03:36:15
Проблема в том, что иногда люди перепродают свою идеологию, и вы потенциально можете зарабатывать на жизнь, продавая сайты только на html и javascript, если бы у вас была хорошая методология для их проверки.
Mark Rogers 6.03.2009 16:02:23

Объекты в моих приложениях имеют тенденцию относиться один к одному с базой данных, но я обнаружил, что использование Linq To Sql вместо sprocs значительно облегчает написание сложных запросов, особенно возможность их построения с использованием отложенного выполнения. например, из r в Images.User.Ratings где и т. д. Это избавляет меня от попыток отработать несколько операторов соединения в sql, а использование Skip & Take для подкачки страниц также упрощает код, а не встраивает код row_number & 'over'.

0
12.09.2008 03:04:29
Есть большая опасность, поступая таким образом. Большинство сложных запросов в конечном итоге должны быть полностью переписаны администратором базы данных для их масштабирования. Никакая настройка индекса не может сделать то, что иногда может сделать изменение запроса. Этот тип Linq2Sql является чрезвычайно жесткой связью.
Eric Z Beard 12.09.2008 03:22:54

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

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

Я могу понять ваше неприятие ORM, если ваш опыт в основном состоит из Java EE и CSLA. Возможно, вы захотите взглянуть на LINQ to SQL, который является очень легковесной структурой и представляет собой, в первую очередь, сопоставление «один к одному» с таблицами базы данных, но обычно требуется лишь незначительное расширение, чтобы они были полноценными бизнес-объектами. LINQ to SQL также может отображать объекты ввода и вывода в параметры и результаты хранимых процедур.

Платформа ADO.NET Entity имеет дополнительное преимущество, заключающееся в том, что таблицы вашей базы данных можно просматривать как классы сущностей, наследуемые друг от друга, или как столбцы из нескольких таблиц, объединенные в одну сущность. Если вам нужно изменить схему, вы можете изменить отображение с концептуальной модели на схему хранения без изменения фактического кода приложения. И снова, хранимые процедуры могут быть использованы здесь.

Я думаю, что больше ИТ-проектов на предприятиях терпят неудачу из-за неосуществимости кода или низкой производительности разработчика (что может произойти, например, из-за переключения контекста между написанием sproc-записи и написанием приложения), чем проблемы масштабируемости приложения.

4
4.07.2012 13:49:26
Я думаю, что хорошим компромиссом было бы сопоставление ORM с хранимыми процедурами, за исключением того, что это легко можно сделать плохо: если вы просто создадите 4 CRUD-процесса для каждой таблицы, вы ничего не добились. Можете ли вы отобразить большие, крупнозернистые процы на сущности, или это вас никуда не приведет?
Eric Z Beard 12.09.2008 03:49:08
В дополнение к операциям CRUD, Microsoft ORM позволяет добавлять методы в классы сущностей, которые отображаются непосредственно на любой сохраненный процесс, который вы хотите использовать (при условии, что все типы ввода / вывода сопоставимы).
Mark Cidade 12.09.2008 04:05:47

Я думаю, что вы можете «кусать больше, чем можете прожевать» по этой теме. Тед Ньюард не был легкомысленным, когда назвал это « Вьетнамом информатики ».

Одна вещь, которую я могу вам абсолютно гарантировать, это то, что она никого не изменит в этом вопросе, как это часто доказывалось на бесчисленных других блогах, форумах, подкастах и ​​т. Д.

Это, конечно, хорошо иметь открытые disucssion и дебаты о спорной теме, просто это один было сделано так много раз, что обе «стороны» согласились не соглашаться и просто уживался с написания программного обеспечения.

Если вы хотите продолжить чтение с обеих сторон, посмотрите статьи в блоге Теда, Айенде Рахейн, Джимми Нильсона, Скотта Беллвера, Alt.Net, Стивена Форте, Эрика Эванса и т. Д.

8
9.02.2010 08:16:53
Вы правы, большинство людей не изменит свое мнение. Я понимаю, что в центре внимания переполнения стека должны быть объективные вопросы, но субъективные гораздо веселее! Лично я многому научился из этой дискуссии.
Eric Z Beard 12.09.2008 11:18:09
Я думаю, что различные подходы зависят от конкретного контекста, и что это обсуждение может помочь выяснить, какие сценарии выигрывают или отвлекают от различных моделей персистентности. Эксперты по этой теме не будут быстро менять свое мнение, но это сайт с вопросами, где люди ищут опыт других.
TheXenocide 17.09.2008 20:50:24
Вау. +1 за ссылку на статью «Вьетнам компьютерных наук», в которой есть отличное введение в тему ORM и не ORM.
lambacck 22.08.2010 20:28:16

Вы можете найти этот пост на comp.object интересным.

Я не утверждаю, что согласен или не согласен, но это интересно и (я думаю) имеет отношение к этой теме.

3
19.09.2008 23:13:40
Это отличный пост. Подводит итог моим мыслям об ОРМ почти идеально.
Eric Z Beard 20.09.2008 01:22:53

Не так много времени в данный момент, но только с моей головы ...

Сущностная модель позволяет предоставить согласованный интерфейс для базы данных (и других возможных систем) даже за пределами возможностей интерфейса хранимых процедур. Используя корпоративные бизнес-модели, вы можете быть уверены, что все приложения последовательно влияют на данные, что ОЧЕНЬ важно. В противном случае вы получите плохие данные, которые просто зло.

Если у вас есть только одно приложение, значит, у вас нет «корпоративной» системы, независимо от того, насколько велики это приложение или ваши данные. В этом случае вы можете использовать подход, аналогичный тому, о котором вы говорите. Просто знайте о работе, которая потребуется, если вы решите развивать свои системы в будущем.

Вот несколько вещей, которые вы должны иметь в виду (IMO), хотя:

  1. Сгенерированный код SQL плохой (исключения, которым нужно следовать). Извините, я знаю, что многие думают, что это экономит много времени, но я никогда не находил систему, которая могла бы генерировать более эффективный код, чем то, что я мог бы написать, и часто код просто ужасен. Вы также часто заканчиваете тем, что генерируете тонну кода SQL, который никогда не используется. Исключение составляют очень простые шаблоны, например, таблицы поиска. Многие люди увлекаются этим.
  2. Entities <> Таблицы (или даже объекты логической модели данных обязательно). Модель данных часто имеет правила данных, которые должны применяться как можно ближе к базе данных, которые могут включать в себя правила относительно того, как строки таблицы связаны друг с другом, или другие подобные правила, которые слишком сложны для декларативного RI. Это должно быть обработано в хранимых процедурах. Если все ваши хранимые процедуры - простые CRUD-процессы, вы не сможете этого сделать. Вдобавок ко всему, модель CRUD обычно создает проблемы с производительностью, потому что она не сводит к минимуму поездки по сети к базе данных. Это часто самое большое узкое место в корпоративном приложении.
1
21.10.2008 15:13:55
Договорились о сгенерированном SQL. Это всегда вызывает больше проблем, чем решает. И я очень против простого создания слоя CRUD с сохраненными процессами. Процессы должны быть как можно более крупными. Не уверен, как вы определяете «одно приложение».
Eric Z Beard 21.10.2008 16:52:40
Под одним приложением я подразумеваю одно приложение, написанное одной группой в организации. Там, где я сейчас консультируюсь, у них есть корпоративная база данных, к которой обращаются как минимум три отдельные группы, работающие над тремя различными приложениями с ограниченной связью между ними.
Tom H 23.10.2008 15:48:47

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

0
21.10.2008 16:24:11
Я не вижу ОО как "пух". Просто за последние десять лет MSFT, Sun и т. Д. Написали 99% объектов, которые нам когда-либо понадобятся. То, что я пишу много статических классов поверх фреймворка, не означает, что я не использую OO.
Eric Z Beard 21.10.2008 16:55:27

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

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

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

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

Это правда, что данные живут дольше, чем приложения, но учтите эту цитату из Дэвида Лариби : модели вечны ... данные - это счастливый побочный эффект.

Еще несколько ссылок на эту тему:

4
5.11.2008 10:25:54
Честно говоря, я начинаю верить, что данные живут дольше, чем программное обеспечение вокруг них, потому что зачастую так мало внимания уделяется разработке программного обеспечения в соответствии с истинным пониманием бизнеса.
flq 4.03.2009 18:19:52

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

Интересно, будет ли лучше использовать модель персистенции isam для базы данных; лучший импеданс соответствует ОО; большее согласие с основной идеей данных в виде таблиц; более соответствует обычным артефактам персистентности ОО. Хорошим примером является то, что ФК и их ассоциации могут быть более явными.

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

Кто-нибудь пытался использовать базу данных isam для реализации ActiveRecord?

0
6.11.2008 20:44:52

Я действительно не уверен, что вы считаете "Корпоративные приложения". Но у меня складывается впечатление, что вы определяете его как внутреннее приложение, в котором СУБД была бы установлена, и система не должна была бы взаимодействовать с любыми другими системами, внутренними или внешними.

Но что если у вас есть база данных со 100 таблицами, которые равны 4 хранимым процедурам для каждой таблицы только для базовых операций CRUD, то есть 400 хранимых процедур, которые необходимо поддерживать и не строго типизированы, поэтому подвержены опечаткам и не могут быть проверены модулем , Что происходит, когда вы получаете нового технического директора, который является евангелистом с открытым исходным кодом и хочет изменить СУБД с SQL Server на MySql?

Сегодня много программного обеспечения, будь то корпоративные приложения или продукты, использующие SOA, и предъявляют некоторые требования для предоставления доступа к веб-службам, по крайней мере, программное обеспечение, с которым я работаю. Используя ваш подход, вы в конечном итоге выставите Serialized DataTable или DataRows. Теперь это может считаться приемлемым, если Клиент гарантированно находится в .NET и во внутренней сети. Но когда Клиент не известен, вы должны стремиться разработать API, который будет интуитивно понятным, и в большинстве случаев вы не захотите раскрывать схему полной базы данных. Я, конечно, не хотел бы объяснять разработчику Java, что такое DataTable и как его использовать. Есть также рассмотрение Bandwith и размера полезной нагрузки и сериализованных DataTables, DataSets очень тяжелые.

Не существует серебряной пули с программным дизайном, и это действительно зависит от того, где лежат приоритеты, для меня это в коде Unit Testable и слабосвязанных компонентах, которые могут быть легко использованы любым клиентом.

только мои 2 цента

2
11.11.2008 09:29:06
Нет, мое определение корпоративного приложения противоположное. Схема часто меняется, и есть много приложений, которые используют базу данных, и она взаимодействует со многими внешними партнерами. В реальном корпоративном приложении вы никогда и никогда не перейдете на другую СУБД. Такого просто не бывает.
Eric Z Beard 11.11.2008 18:57:23
И создание 4 процедур для каждой таблицы - плохая практика. Он тесно связывает вас с моделью данных, как сгенерированный sql из ORM, поэтому он ничего не покупает. Процессы должны быть грубыми бизнес-операциями, а не просто CRUD для каждой таблицы.
Eric Z Beard 11.11.2008 19:04:16
Но разве это не ответ ?: чем больше кода вам нужно написать, тем больше вам нужно функций для поддержки крупномасштабного программирования: инкапсуляция, строковый тип, рефакторинг, сложный стиль и проверка ошибок и т. Д .; Java и .NET имеют обширную поддержку в этой области, а языки хранимых процедур - нет.
reinierpost 1.04.2009 16:09:16

Действительно интересный вопрос. Честно говоря, я не могу доказать, почему сущности хороши. Но я могу поделиться своим мнением, почему они мне нравятся. Код вроде

void exportOrder(Order order, String fileName){...};

Он не заботится о том, откуда поступил заказ - из БД, из веб-запроса, из модульного теста и т. д. Он заставляет этот метод более явно объявлять, что именно ему требуется, вместо того, чтобы брать DataRow и документировать, какие столбцы он ожидает и какие типы им следует быть. То же самое применимо, если вы реализуете его как-то как хранимую процедуру - вам все равно нужно вставить в него идентификатор записи, в то время как он не обязательно должен присутствовать в БД.

Реализация этого метода будет осуществляться на основе абстракции Порядка, а не на том, как именно он представлен в БД. Большинство таких операций, которые я реализовал, на самом деле не зависят от того, как хранятся эти данные. Я понимаю, что некоторые операции требуют соединения со структурой БД для повышения производительности и масштабируемости, просто по моему опыту их не так уж много. По моему опыту очень часто достаточно знать, что Person имеет .getFirstName (), возвращающую String, и .getAddress (), возвращающую Address, и address имеет .getZipCode () и т. Д., И не заботится о том, какие таблицы вызываются для хранения этих данных. ,

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

Масштабируемость является здесь интересным моментом - большинство веб-сайтов, которым требуется огромная масштабируемость (например, facebook, livejournal, flickr), склонны использовать аскетический подход к БД, когда БД используется настолько редко, насколько это возможно, и проблемы с масштабируемостью решаются с помощью кэширования, особенно с использованием ОЗУ. На http://highscalability.com/ есть несколько интересных статей.

4
11.11.2008 10:42:07
Масштабируемость в корпоративных приложениях не всегда может быть решена с помощью кэширования, так как большая его часть часто изменяет данные транзакций в таблицах с миллионами строк. Я вижу Facebook и др. и др. как веб-сайты большого объема, где трудная часть обслуживает так много веб-запросов.
Eric Z Beard 11.11.2008 19:01:03

Я озадачен аргументом «заблокируй свою базу данных в камне» в пользу хранимых процедур. Я могу взять свою модель ActiveRecord и переместить ее с MySQL на Postgres на SQLite, большое спасибо. Я не смог бы сделать это с чем-нибудь, хранящимся на основе proc, если бы я не хотел переписать их все.

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

Мой опыт работы с системами на основе хранящихся процедур минимален. Мне интересно, в больших приложениях, как вы управляете всеми отношениями данных? На одной странице я показываю товар с изображением. На другой странице я показываю продукт и пользователя, который его создал. На другой странице я показываю продукт и комментарии о нем. На другой странице мне нужно показать, что продукт без изображения объединен с таблицей спецификаций об этом .... и т. Д. И т. Д. У меня есть модель данных с множеством взаимосвязей. Я полагаю, вы не пишете сохраненный процесс для каждой комбинации? Принцип СУХОГО - тот, о котором я беспокоюсь. Сколько запросов я пишу, где я снова присоединяюсь (эффективно перекодирую) мои отношения? И, пока мы говорим о блокировке схемы, сколько хранимых процедур мне нужно будет переписать?

0
3.12.2008 06:49:10
Да, у вас много повторений в SQL. Вы обычно жертвуете СУХОЙ для производительности. Процессы очень грубые: они существуют для определенных целей и не используются повторно. Вы правы, блокировка «схемы» в камне более уместна.
Eric Z Beard 3.12.2008 20:39:25
Аргумент об изменении поставщиков rdbms не применим к корпоративному приложению. Если вы сталкиваетесь с такой возможностью, вы не работаете над корпоративным приложением, IMO.
Eric Z Beard 3.12.2008 20:40:14

Я хотел бы предложить другой взгляд на проблему расстояния между ОО и РБД: история.

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

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

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

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

Поэтому многие из нас хотели использовать ОО, но мы все еще хотим безопасное хранение наших данных. Что может быть безопаснее, чем хранить наши данные так же, как это делает уважаемая система бухгалтерского учета? Это заманчивые перспективы, но мы все сталкиваемся с одними и теми же ловушками. Очень немногие взяли на себя труд думать о постоянстве OO по сравнению с огромными усилиями RDB-индустрии, которая воспользовалась традициями и положением бухгалтерского учета.

Prevayler и db4o - некоторые предложения, я уверен, что есть и другие, о которых я не слышал, но ни один из них, кажется, не получил половину прессы, как, скажем, спящий режим.

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

В своей повседневной борьбе за преодоление пропасти между ОО и РБД я использую ОО как можно чаще, но стараюсь свести наследство к минимуму. Я не часто использую SP. Я буду использовать расширенный запрос только в аспектах, которые похожи на учет.

Я буду рад, когда меня пропадут, когда пропасть навсегда закроется. Я думаю, что решение придет, когда Oracle запустит что-то вроде «Oracle Object Instance Base». Чтобы действительно завоевать популярность, у него должно быть обнадеживающее имя.

2
3.12.2008 08:24:58
Я не думаю, что вам нужно ORM, чтобы ОО считалось полезным. Я использую хранимые процедуры и пишу много статических вспомогательных классов в своем коде, но эти классы построены на огромной платформе .NET, которая представляет собой фантастическую коллекцию объектов.
Eric Z Beard 3.12.2008 20:46:18
Ваша логика имеет смысл, но я не думаю, что предпосылка правильна. Я никогда не слышал ни о чем, что нельзя сопоставить с RDB.
Jeff Davis 14.07.2009 16:40:59

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

0
15.12.2008 19:17:16