Что лучше использовать анемичную модель для хранения данных аля

public class Person {
  public string Name {get;set;}
}

interface IPersonService {
    Person ChangeName(Person person, string name);
    string Greeting(Person person);
}

или же

public class Person {
  public string Name {get;private set;}
 public void ChangeName(string name) {Name  = name;}

    public string Greeting()=> $"Hello, {Name}";
}

что в конечном счете даст больще преимуществ?

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

Или быть может хороший компромисс сделать так

class Entity {
    // public void Add (Source src) {....}
    public void Add (Source src, Func<Dest,Source> mapper) {....}
}

Лучше использовать анемичную модель.

Здравствуйте, vsb, Вы писали:

vsb>Лучше использовать анемичную модель.

Let the holy war begin

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

Здравствуйте, Mr.Delphist, Вы писали:

MD>Использовать лучше то, что даст меньше проблем в текущей ситуации. Именно поэтому делаются "вроде бы странные" вещи типа денормализации данных, NoSQL и т.п.

Ну тема конкретно про объектную модель против анемичной. Для меня мой текущий подход к использованию анемичной модели совсем не был очевиден раньше. Но чем больше я читал апологетов объектно-ориентированного подхода, тем больше укреплялся во мнении, что это всё чушь собачья. Понятно, что ToStringService заводить глупо. Хотя опять же могут быть нюансы. Лично моё мнение сейчас — для типового кода достаточно процедурного программирования со структурами и элементами функционального программирования (лямбды). Все объектно-ориентированные навороты делают код строго хуже. Вместо полиморфизма нужно использовать switch (в идеале с паттерн-матчингом, если язык даёт). Вместо наследования нужно использовать агрегацию. Единственное, что от ООП полезно это концепция интерфейса и нескольких реализаций, хотя не уверен, что эта концепция вообще от ООП. Ну и процедуры объединяются в классы, которые потом через Dependency Injection связываются друг с другом.

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

Раньше я считал, что ООП хорошо подходит под программирование GUI. Но потом я увидел реакт и понял, что ООП и тут не нужен.