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

139
задан 4 revs, 3 users 95% 18 June 2016 в 16:18
поделиться

38 ответов

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

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

59
ответ дан Kristopher Johnson 18 June 2016 в 16:18
поделиться

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

  1. , Как был бы Вы модульный тест, если вся Ваша бизнес-логика была в Вашей базе данных?
  2. не Был бы изменения в Вашей структуре базы данных, конкретно, которые влияют на несколько страниц в Вашем приложении, главная стычка для изменения всюду по приложению?
0
ответ дан Kevin Pang 18 June 2016 в 16:18
поделиться

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

Независимо от того, что Вы делаете, это не ООП. Это не неправильно, это - просто не ООП, и не имеет смысла применять Ваши решения каждой othe проблемы там.

0
ответ дан Outlaw Programmer 18 June 2016 в 16:18
поделиться

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

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

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

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

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

2
ответ дан Guy Starbuck 18 June 2016 в 16:18
поделиться

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

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

2
ответ дан Eric Z Beard 18 June 2016 в 16:18
поделиться

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

4
ответ дан FlySwat 18 June 2016 в 16:18
поделиться

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

3
ответ дан 2 revs 18 June 2016 в 16:18
поделиться

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

7
ответ дан Eric Z Beard 18 June 2016 в 16:18
поделиться

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

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

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

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

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

3
ответ дан tgmdbm 18 June 2016 в 16:18
поделиться

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

4
ответ дан jdecuyper 18 June 2016 в 16:18
поделиться

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

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

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

16
ответ дан NotMe 18 June 2016 в 16:18
поделиться

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

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

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

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

22
ответ дан Webjedi 18 June 2016 в 16:18
поделиться

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

то, Что я делаю, использовать Разработку через тестирование, таким образом, я пишу свои уровни UI и Model сначала, и уровень Data дразнят, таким образом, UI и модель являются сборкой вокруг зависящих от домена объектов, затем позже я отображаю эти объекты на то, что когда-либо технология я использую Слой Данных. Это - плохая идея позволить структуре базы данных определить дизайн Вашего приложения. Где возможная запись приложение сначала и позволила тому влиянию структура Вашей базы данных, не наоборот.

25
ответ дан 2 revs 18 June 2016 в 16:18
поделиться

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

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

то, Что (по-моему), объекты приносит к проекту:

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

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

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

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

Аплодисменты.

11
ответ дан Julio César 18 June 2016 в 16:18
поделиться

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

, Таким образом, я предполагаю, Вы подвергаете сомнению тот подход, а именно, разделяя проблемы.

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

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

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

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

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

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

27
ответ дан 2 revs 18 June 2016 в 16:18
поделиться

Объекты в моих приложениях имеют тенденцию иметь отношение непосредственный к базе данных, но я нахожу использование, Linq К Sql, а не sprocs делает это, намного более легкая запись усложнила запросы, особенно способность создать их использование задержанного выполнения. например, от r в Изображениях. Пользователь. Оценки, где и т.д. Это сохраняет меня пытающийся разработать несколько операторов соединения в sql, и имеющий Пропуск & Возьмите для подкачки страниц, также упрощает код вместо того, чтобы иметь необходимость встроить row_number & 'по' коду.

0
ответ дан peterorum 18 June 2016 в 16:18
поделиться
  • 1
    о, извините получите неверное представление – Kotzilla 8 August 2013 в 04:32

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

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

, Например,

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

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

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

0
ответ дан Allain Lalonde 18 June 2016 в 16:18
поделиться
  • 1
    Хорошо, взгляды лучше и имеют больше смысла после Вашего редактирования.:) – Zarepheth 8 August 2013 в 12:48

Eric,

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

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

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

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

2
ответ дан Jon Limjap 18 June 2016 в 16:18
поделиться

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

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

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

, Если Вы хотите сделать некоторые дополнительные материалы для чтения с обеих сторон, см. статьи о блоге Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Высоком звуке. Сеть, Stephen Forte, Eric Evans и т.д.

8
ответ дан 4 revs, 2 users 84% 18 June 2016 в 16:18
поделиться

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

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

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

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

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

4
ответ дан 3 revs, 2 users 94% 18 June 2016 в 16:18
поделиться

Вы могли бы найти этот сообщение на comp.object интересный.

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

3
ответ дан Hamish Smith 18 June 2016 в 16:18
поделиться

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

0
ответ дан Pragmatic Agilist 18 June 2016 в 16:18
поделиться
  • 1
    Пример кода var filename = $('input[type=file]').val().replace(/.*(\/|\\)/, ''); использует jQuery. – Zarepheth 7 August 2013 в 17:50

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

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

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

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

  1. Сгенерированный код SQL плох (исключения для следования). Извините, я знаю, что много людей думает, что экономит время, но я никогда не находил систему, которая могла сгенерировать более эффективный код, чем, что я мог записать, и часто код просто ужасен. Вы также часто заканчиваете тем, что генерировали тонну кода SQL, который никогда не привыкает. Исключением здесь являются очень простые шаблоны, как, возможно, справочные таблицы. Много людей увлекается на нем все же.
  2. Объекты <> Таблицы (или даже объекты логической модели данных обязательно). Модель данных часто имеет правила данных, которые должны быть осуществлены максимально тесно к базе данных, которая может включать правила вокруг, как строки таблицы касаются друг друга или других подобных правил, которые слишком сложны для декларативного RI. Они должны быть обработаны в хранимых процедурах. Если всеми Вашими хранимыми процедурами является простой CRUD procs, Вы не можете сделать этого. Вдобавок ко всему, модель CRUD обычно создает проблемы производительности, потому что она не минимизирует распространения в прямом и обратном направлениях по сети к базе данных. Это часто - самое большое узкое место в корпоративном приложении.
1
ответ дан Tom H 18 June 2016 в 16:18
поделиться
  • 1
    Различие между HSL и HSB (иногда также названный HSV) цветовая модель - то, что в HSB L = 1.0 соответствует чистому цвету, тогда как в HSL L = 1.0 соответствует белый и L = 0.5 к чистому цвету. Начиная с исходного плаката, который спрашивают, например, для способа сделать цветной синий (RGB=0/0/1) легче, я думаю, что HSL более гибок. – Martin R 22 July 2012 в 19:03

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

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

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

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

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

Масштабируемость является интересным моментом здесь - большинство веб-сайтов, которые требуют, чтобы огромная масштабируемость (как Facebook, Живой Журнал, flickr) имела тенденцию использовать аскетический DB подход, когда DB используется максимально редкий, и проблемы масштабируемости решены путем кэширования, особенно Использованием оперативной памяти. http://highscalability.com/ имеет некоторые интересные статьи о нем.

4
ответ дан Pavel Feldman 18 June 2016 в 16:18
поделиться
  • 1
    Это, которое приведут к сбою методы, если они будут использоваться на серых оттенках. getHue:saturation:brightness:alpha возвратит FALSE. – Matthieu Riegler 15 May 2014 в 10:34

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

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

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

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

просто мои 2 цента

2
ответ дан user17060 18 June 2016 в 16:18
поделиться

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

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

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

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

Это верно, что данные живут дольше, чем приложения, но рассмотрите эта кавычка от David Laribee : Модели являются навсегда... данными, счастливый побочный эффект.

еще Некоторые ссылки на эту тему:

4
ответ дан jbandi 18 June 2016 в 16:18
поделиться
  • 1
    Я думаю, что существует что-то путающее в Вашем ответе: Вы проявляете эти два подхода (один с RGB и другим с HSB для версии категории), который don' t имеют тот же результат... И это может быть вопросом значения: освещение действительно для меня заставляющий цвет склоняться к белому (темнеющий к черному цвету), в то время как изменение яркости/значения делает его более сильным (resp. легче). – rchampourlier 4 June 2013 в 21:11

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

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

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

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

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

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

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

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

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

я буду счастливо supprised, когда пропасть будет закрыта навсегда. Я думаю, что решение прибудет, когда Oracle запустит что-то как "Основа Экземпляра объекта Oracle". Для реального завоевывания популярность это должно будет иметь имя заверения.

2
ответ дан Guge 18 June 2016 в 16:18
поделиться

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

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

1
ответ дан billybob 18 June 2016 в 16:18
поделиться

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

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

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

Это хорошо для определенного класса сред, но это, конечно, не покрывает целый спектр Корпоративные приложения .

3
ответ дан Renaud Bompuis 18 June 2016 в 16:18
поделиться

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

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

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

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

1
ответ дан Mark Rogers 18 June 2016 в 16:18
поделиться
  • 1
    Почему RGB использования, когда можно сделать то же с оттенком, насыщенностью, яркостью, тогда просто восстанавливает цвет с измененной яркостью? – jrturton 22 July 2012 в 18:51
Другие вопросы по тегам:

Похожие вопросы: