Должны ли мы сначала делать моделирование отношений сущностей или объектно-ориентированное моделирование?


9

Следует ли при создании приложения с нуля начинать с объектно-ориентированной (ОО) модели или модели сущности-отношения (ER)?

Ответы:


13

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

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

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


7

Модель ER определяет, как будут сохраняться данные приложения, а модель OO решает, как эти же данные будут храниться в памяти или во время работы приложения. Таким образом, проектирование схемы базы данных (модель ER) и проектирование структуры класса (модель OO) являются связанными проектными соображениями, и о них обычно даже можно думать одновременно. Фактически, если вы используете инструмент объектно-реляционного отображения (ORM) , ваша модель ER и модель OO могут быть одинаковыми. Другими словами, ваши классы (модель OO) могут быть аннотированы таким образом, что они сами определяют модель ER.

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


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

@ EmmadKareem Вы правы, не всегда уместно думать о двух моделях одновременно. Я говорил об идее использования ORM и аннотирования классов, чтобы дизайн ER-модели был интегрирован в OO-модель, так сказать. Некоторые люди предпочитают разрабатывать приложения таким способом, который, по сути, реализует OO и ER одновременно.
CFL_Jeff

Не путайте вашу модель предметной области с моделью данных. Не путайте объект (представляющий один экземпляр) с таблицей базы данных (которая содержит набор вещей).
Narender Parmar
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.