A>Зачем все возводить в абсолют? Если стройная, то аннорексия, если жирная, то высшая степень ожирения

public interface IProjectManagement
{
  void SetProjectLead(Project project, ParticipantId lead);
    void AssignProject(Project project, ParticipantId assignee);
    void AddParticipant(Project project, ParticipantId participant);
    void RemoveParticipant(Project project, ParticipantId participant);
}

S>public interface IProjectManagement
S>

public class Project
{
    private IProjectManagement _manager; // как-то инджектится в проект
    
    public Participant ProjectLead
    {
        get {return _projectLead;}
        
        set
        {
            _manager.SetProjectLead(this, value); // каким-то образом менеджер устанавливает свойства
        }
    }
}

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

project.ID++;

bool Validate(Project)

- Single Responsibility Principle (SRP). Хранение данных в классе — это уже одна, вполне самостоятельная обязанность, добавление другой логики в класс приводит к нарущению этого принципа.

Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД

И, возвращаясь к Entity Framework, в свете всего вышеописанного, тот факт, что он "провоцирует" проектировать приложения в "стройной" модели и не поддерживает Lazy Loading, требуя явной загрузки всех необходимых данных, я склонен считать достоинством.

документ который содержит строку: "The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes" подписали 580 человек, в чиcле них и один из разработчиков портирующих hibernate под платформу .NET

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

Проблема в том, что в "жирной" модели, еще на этапе проектирования приложения нужно не просто обозначить ничего не обязывающую связь один ко многим, между заказом и продуктами в него входящими, а явно сказать, что коллекция объектов OrderItems принадлежит объекту Order

- Single Responsibility Principle (SRP). Хранение данных в классе — это уже одна, вполне самостоятельная обязанность, добавление другой логики в класс приводит к нарущению этого принципа. Таким образом, вынос логики из класса производится в строгом соответствии SRP.

class CustomerFrame
{
  int Id { get; }
  string Name { get; set; }
}

class Customer : CustomerFrame
{
  OrderItemList Orders { get; }
}

class Order<T> where T : IPersistanceModel
{
  void Save()
  {
    persistanceModel.Save(this);
  }
}

Order<Database> order = ...
order.Save();

class OneToManyRelation<TParent,TChild>
{
    TParent Parent { get; }
    
    List<TChild> Children { get; }
}

- Иногда письма не доходят.
— Да, бывалыча пишешь письмо, получаешь ответ и понимаешь — не дошло письмо, не дошло.

Именно по этому, привязывать определенным данным какое-либо поведение посредством "жирной" модели — дурная затея. Во-первых, меняя в десятый раз поведение данные нужно оставлять неизменными. Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое и не накручивать поверх старого, при этом стараясь оставить данные по прежнему неизменными.
...
Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД — то, когда понадобится хранить те же данные в кеше, вьюстейте, сессии или сериализовать еще куда-нибудь, придется либо добавить еще один метод .Save(), то есть, модифицировать существующий класс, вместо того, чтобы просто добавить новый, либо размещать новый Save() в другом классе, не понятно по какой причине ставя Save() в базу данных в привилегированное положение по отношению к другим Save-ам.
...
На первый взгляд, кажется что в "жирнной" модели код хорошо инкапсулирован, но это не так. На самом деле, как это ни странно, лучше всего код инкапсулруется именно "стройной" модели. Инкапсуляция призвана скрывать детали реализации за публичным контрактом. Однако, в случае "жирной" модели детали реализации, допустим, сериализации в XML никак не скрыты от деталей реализации какого-нибудь рассчета или сохранения в БД, в рамках одного "жирного" класса. Этот никак, по смыслу, не связанный между собой функционал, вполне может начать влиять друг на друга при неаккуратной реализации, а компилятор никак не сможет это дело проконтролировать.

IB>У него, конечно, много чего упомянуто, но подобного там точно нет.

The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters

public class Order
{
    public int OrderId {get;set;}
    ....
    public void Save()
    {
        // Сохранение в БД
    }
}

    public Pet loadPet(int id) throws DataAccessException {
        JdbcPet pet = (JdbcPet) this.petQuery.findObject(id);
        if (pet == null) {
            throw new ObjectRetrievalFailureException(Pet.class, new Integer(id));
        }
        Owner owner = loadOwner(pet.getOwnerId());
        owner.addPet(pet);
        loadVisits(pet);
        return pet;
    }

public class JdbcPet extends Pet {
    private int typeId;
    private int ownerId;

    public void setTypeId(int typeId) {
        this.typeId = typeId;
    }
    public int getTypeId() {
        return this.typeId;
    }
    public void setOwnerId(int ownerId) {
        this.ownerId = ownerId;
    }
    public int getOwnerId() {
        return ownerId;
    }
}