У меня есть коллекция таких объектов
public class ApplicationConfiguration
{
public virtual long ApplicationConfigurationId { get; set; }
public virtual Site Site { get; set; }
public virtual ApplicationParameters ApplicationParameters { get; set; }
public virtual IList<ApplicationParameters> ApplicationParametersHistory { get; set; }
}
public class ApplicationParameters
{
public virtual int ApplicationParametersId { get; set; }
public virtual Site Site { get; set; }
public virtual int Status { get; set; }
}
public class Site
{
public virtual int SiteId { get; set; }
}
Я хочу, чтобы моя модель работала так, чтобы все они были связаны между собой объектом моего сайта. Моя бизнес-логика гарантирует, что один ApplicationParameters
является «активным», а остальные хранятся в коллекции History.
Моя проблема возникает при сопоставлении их вместе с Fluent. У меня есть что-то вроде этого
public class ApplicationConfigurationMap : ClassMap<ApplicationConfiguration>
{
public ApplicationConfigurationMap()
{
Table("MerchantApplicationConfigurations");
Id(x => x.ApplicationConfigurationId, "MerchantApplicationConfigurationId").GeneratedBy.Identity();
References<Site>(x => x.Site, "SiteId");
References<ApplicationParameters>(x => x.ApplicationParameters, "ApplicationParametersId");
}
}
Но как мне сопоставить мою коллекцию, чтобы забрать все ApplicationParameters
со статусом 4, где у братьев и сестер одинаковый SiteId? Я знаю, что могу использовать .Where("Status = 4")
, но в остальной части сопоставления я не уверен.
EDIT
Мне нужно немного уточнить мой дизайн.
Сайт - это внешний объект, используемый в устаревших системах, поэтому я не могу его изменить. При создании этих приложений (бумажных, а не программных) я должен сохранять полную историю всех изменений. Я разбил приложение на кучу разных частей, и этот объект конфигурации является основой для стороны приложения, которое мы настраиваем (цены, сборы и т. Д.).
Способ работы этой системы заключается в том, что каждая часть может быть отредактирована, и когда это так, я создаю новую запись с активным статусом, а затем предыдущий элемент (ы) с неисторическим статусом устанавливается на исторические. Таким образом, в данный момент активна только одна запись для каждого сайта.
Я забираю свои данные по сайту, потому что я всегда могу выбрать активные компоненты для этого сайта. Если я связываю свои части приложения с ApplicationConfiguration
, это означает, что базовый объект больше не может следовать моей исторической модели сохранения. Я также хочу избежать отрывания всех частей по отдельности и создания DTO.
Я не хотел присоединять все к объекту Site
, потому что он используется в других приложениях, которые используют эту кодовую базу. Эта модель данных используется только в приложении администратора, поэтому я хотел отделить ее от объекта Site, который используется в приложениях администратора и клиента.