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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

Я нашел ваш вопрос действительно интересным.

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

Ответ 10

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

Ответ 11

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

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

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

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

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

Ответ 12

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

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

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

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

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

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

• Почему сеттеры и Getters злы

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

• POJO против NOJO

• Super Models Part 2

• TDD, Mocks и дизайн

Ответ 13

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

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

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

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

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

Ответ 16

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

Я не претендую на согласие или несогласие, но это интересно и (я думаю), относящееся к этой теме.

Ответ 17

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

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

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

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

Ответ 18

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

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

Ответ 19

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

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

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

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

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

Ответ 20

Эрик,

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

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

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

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

Ответ 21

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

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

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

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

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

Ответ 22

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

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

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

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

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

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

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

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

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

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

Ответ 23

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

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

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

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

• Сгенерированный код SQL плох (исключения, которые следует соблюдать). Извини я знаю, что многие люди думают, что это огромная экономия времени, но я никогда не находили систему, которая могла бы генерировать более эффективный код, чем что я мог бы написать, и часто код просто ужасен. Вы также часто в конечном итоге генерируют тонну кода SQL, который никогда не используется. Исключение здесь очень просто шаблоны, например, таблицы поиска. Многие люди увлекаются это хотя.
• Entities < > Таблицы (или даже логические объекты модели данных обязательно). У модели данных часто есть правила данных, которые должны быть соблюдены как можно ближе к базе данных, которая может включать в себя правила о том, как строки таблицы связаны друг с другом или другие подобные правила, которые слишком сложны для декларативного RI. Они должны обрабатываться в хранимых процедурах. Если все ваши хранимые процедуры являются простыми процедурами CRUD, вы не можете этого сделать. Кроме того, модель CRUD обычно создает проблемы с производительностью, поскольку она не сводит к минимуму круглые поездки по сети в базу данных. Это часто является самым большим узким местом в корпоративном приложении.

Ответ 24

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

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

Ответ 25

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

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

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

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

Ответ 26

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

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

Ответ 27

Интересный вопрос. Несколько мыслей:

• Как вы unit test, если бы вся ваша бизнес-логика была в вашей базе данных?
• Не будет ли изменяться структура вашей базы данных, особенно те, которые затрагивают несколько страниц вашего приложения, стать основной проблемой для изменения во всем приложении?

Ответ 28

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

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

Например,

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

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

В основном это тонкий шпон над материалом Database Access, но он по-прежнему дает мне возможность абстрагировать его, когда мне нужно.

Ответ 29

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

Ответ 30

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