Способен ли объект сохранить себя в базе данных, портит ли сплоченность класса?

Question

Говоря с точки зрения объектно-ориентированного проектирования, думаете ли вы, что возможность сохранения себя в базе данных для объекта портит единство класса?

Представьте себе:

Product p = new Product() 
          {
           Name = "Joy Rider", 
           Price = 100, 
           Currency = "USD"
          };

Как вы думаете, лучше сохранить этот продукт p в базе данных лучше всего так:

 p.Save();

или как-то так:

 ProductServices.SaveProduct(p);

Что вы думаете?

Answer 1

Объект, который может сохранить себя в базе данных, будет нарушать SRP (принцип единой ответственности).

Упорство само по себе является обязанностью и должно выполняться специальными классами.

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

Answer 2

Это мешает принципу единой ответственности. Цель класса Product в вашем примере - представить Product и операции над этим продуктом. Взаимодействие с базой данных не является основной частью ответственности класса.

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

Answer 3

С точки зрения объектно-ориентированного проектирования только тогда нет, нет ничего плохого в том, что метод Save является частью Product . Это на самом деле предпочтительный метод в мире объектно-ориентированного дизайна. И с точки зрения чистой ОО вы бы не хотели, чтобы он был разбит на части, потому что это более функционально, чем объект.

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