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

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

Итак, я бы сказал, что нет ответа на one-size-fits-all. Разработчики должны знать, что иногда попытка быть слишком OO может вызвать больше проблем, чем она решает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На каждую строку кода следует смотреть с подозрением.

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

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

То, что (на мой взгляд) сущности привносят в проект-это:

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

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

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

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

Овации.

Я думаю, что вы можете быть "biting off more than you can chew" на эту тему. Тед Ньюард не был легкомысленным, когда называл это "Вьетнам компьютерной науки".

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

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

Если вы хотите продолжить чтение с обеих сторон, смотрите статьи в блоге Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans и др.

@Dan, извините, но это не та вещь, которую я ищу. Я знаю эту теорию. Ваше утверждение "is a very bad idea" не подкреплено реальным примером. Мы стараемся разрабатывать программное обеспечение за меньшее время, с меньшим количеством людей, с меньшим количеством ошибок, и мы хотим иметь возможность легко вносить изменения. Ваша многослойная модель, по моему опыту, является негативной во всех вышеперечисленных категориях. Особенно в том, что касается создания модели данных-это последнее, что вы делаете. Физическая модель данных должна быть важным соображением с первого дня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще несколько ссылок по этой теме:

• Почему сеттеры и геттеры-это зло

• Возвращение чистого OO

• POJO и NOJO

• Супер Модели Часть 2

• TDD, насмешки и дизайн

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

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

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

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

Это экономит время, когда речь заходит о его обслуживании.

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

Вопрос: Как вы управляете отключенными приложениями, если вся ваша бизнес-логика заблокирована в базе данных?

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

При сохранении уровня домена в хранимых процедурах базы данных необходимо придерживаться одного типа приложения, которому требуется постоянное line-of-sight в базе данных.

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

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

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

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

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

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

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

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

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

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

Эрик,

Никто не мешает вам выбрать ту структуру/подход, который вы хотели бы иметь. Если вы собираетесь идти по пути "data driven/stored procedure-powered", то непременно идите по нему! Особенно если это действительно, действительно помогает вам доставлять ваши приложения по спецификации и в срок.

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

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

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

Я хотел бы предложить другой подход к проблеме расстояния между OO и RDB: история.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения, имеющие доменную логику, отделенную от логики хранения данных, могут быть адаптированы к любому источнику данных (базе данных или иным образом)или UI (web или windows (или linux и т. д.)) приложение.

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

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

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

Иногда ваше приложение и уровень данных не настолько тесно связаны. Например, у вас может быть приложение для выставления счетов по телефону. Позже вы создадите отдельное приложение, которое отслеживает использование телефона, Чтобы а) лучше рекламировать вам б) оптимизировать ваш телефонный план.

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

В данный момент времени у меня не так уж много, но я просто сорвался с катушек...

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

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

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

1. Сгенерированный код SQL-это плохо (за исключением следующих случаев). Прости, Я ... знайте, что многие люди так думают это огромная экономия времени, но у меня есть никогда не находил системы, которая могла бы создание более эффективного кода, чем то, что я мог бы написать и часто код просто ужасен. Вы также часто в конечном итоге генерируется тонна из SQL кода, который никогда не используется. Исключение здесь очень простое шаблоны,например, таблицы поиска. Многие люди увлекаются этим но это так.
2. Сущности <> таблицы (или даже логические сущности модели данных обязательно). Модель данных часто имеет правила данных, которые должны быть применены как можно ближе к базе данных, которые могут включать правила о том, как строки таблицы связаны друг с другом или другие подобные правила, которые слишком сложны для декларативного RI. Они должны обрабатываться в хранимых процедурах. Если все ваши хранимые процедуры являются простыми CRUD procs, вы не можете этого сделать. Кроме того, модель CRUD обычно создает проблемы с производительностью, поскольку она не сводит к минимуму круговые поездки по сети к базе данных. Это часто является самым большим узким местом в корпоративном приложении.