DDD “объекты представления”?

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

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

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

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

list.getCompany (1) .getName ()

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

Я использую крошку атрибутов сущности. Например:

// interface for "ID" attribute of Company entity
public interface ICompany_ID {
    Guid CompanyID{get;set;}
}
// interface for "Name" attribute of Company entity
public interace ICompany_Name {
    string Name{get;set;}
}
// interface for "Logo" attribute of Company entity
public interface ICompany_Logo {
    byte[] Logo{get;set;}
}

// interface for all attributes of Company entity
public interface ICompany : ICompany_ID, ICompany_Name, ICompany_Logo { }

// base class for classes based on Company entity
public abstract class CompanyBase : ICompany_ID {
    // implementation of ICompany_ID interface
}

// class for all attributes of Company entity
public class Company : ICompany {
    // implementation of ICompany interface (all attributes)
}

// class for Company name lookup
public class CompanyNameLookup : CompanyBase, ICompany_Name {
   // implementation of ICompany_Name interfade
}

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

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

РЕДАКТИРОВАТЬ: Затем выбор может быть, например:

var companies = (from c in db.Table<ICompany>()
                 order by c.Name
                 select new CompanyNameLookup { ID = c.ID, Name = c.Name }
                ).ToList();

или для типов, созданных данимиками:

var companies = (from c in db.Table<ICompany>()
                 order by c.Name
                 select DynamicTypeFactory.New<ICompany_ID>( c.Id ).And<ICompany_Name>( c.Name ).Create()
                ).ToList();

DynamicTypeFactory - это класс со статическим методом Новый и свободный интерфейс для классов создания данимов при выполнении время.