Programación a interfaces mientras se mapea con Fluent NHibernate

Me doy cuenta de que esto es una distracción, y no una respuesta a su pregunta (aunque creo que mookid lo tiene cubierto).

Realmente deberías evaluar si las interfaces en tus entidades de dominio están realmente proporcionando algo de valor; es raro encontrar una situación en la que realmente necesites hacer esto.

Por ejemplo: ¿Cómo es confiar en IMessage menos acoplado que confiar en Message, cuando ambos (casi) sin duda comparten firmas idénticas? No deberías tener que burlarte. una entidad, porque es raro que tenga suficiente comportamiento para requerir ser burlado.

Puede ajustar su interfaz para que contenga solo un getter:

public interface ISomeEntity
{
    int Id { get; }
}

Su clase concreta todavía puede implementar un setter también, y ya que está programando para sus interfaces nunca llamará al setter "por accidente".

Si desea no permitir la configuración del id incluso cuando mantiene una referencia a una instancia concreta, puede abstenerse de implementar un setter y luego dejar que NHibernate acceda al campo en lugar de a la propiedad-así es, NHibernate puede usar alguna ingeniosa truco de reflexión para establecer su campo id directamente en lugar de invocar la propiedad. Entonces puede mapear el id de esta manera:

Id(e => e.Id).Access.AsCamelCaseField();

En cuyo caso su propiedad Id debe estar respaldada por un campo id correspondiente. Hay más convenciones de nomenclatura, por ejemplo, si prefiere guiones bajos como prefijo de campo privado.

Estoy teniendo exactamente el mismo problema. Desafortunadamente tengo una razón válida para usar interfaces de entidad; el modelo de entidad se implementará de diferentes maneras y con diferentes asignaciones por cliente.

Todo el modelo necesita ser de solo lectura, por lo que las interfaces son del estilo:

public interface IAccount
{
    long AccountId { get; }
    IHouse House { get; }
}

public interface IHouse
{
    long HouseId { get; }
    HouseStatus Status { get; }
    IList<IAccount> Accounts { get; }
}

Implementaciones concretas luego implementarlas con fijadores internos:

public class Account: IAccount
{
    public virtual long AccountId { get; internal set; }
    public virtual IHouse House { get; internal set; }
}

public class House: IHouse
{
    public virtual long HouseId { get; internal set; }
    public virtual HouseStatus Status { get; internal set; }
    public virtual IList<IAccount> Accounts { get; internal set; }
}

He recorrido la ruta del mapeo a las clases concretas. Todo está bien hasta que creas relaciones que devuelven las interfaces y necesitan ser coladas a las implementaciones concretas.

HasMany(x => x.Accounts)

Puede convertirse en

HasMany<Account>(x => x.Accounts)

Pero no hay un 'cast' equivalente para

References(x => x.House)

La asignación a las interfaces (la solución más limpia) genera el problema mencionado anteriormente en el sentido de que el Id debe existir en la clase superior para la configuración y requiere un configurador en la interfaz.

public sealed class AccountMap : ClassMap<IAccount>
{
    public PokerPlayerMap()
    {
        Id(x => x.AccountId, "account_id");

        DiscriminateSubClassesOnColumn("Type").SubClass<Account>(s =>  
        {
            References(x => x.House);       
        });
    }
}

Por ahora, mi única solución es agregar setters a todos los campos de Id de interfaz. Es una pena que la identificación no pueda existir dentro de un subclase o tener su tipo fundido desde la interfaz.

Parece que no tengo suficiente reputación para comentar las respuestas de otras personas, pero como tal, voy a tener que hacer de esta una respuesta en su propio derecho.

References ahora tiene una sobrecarga genérica para permitir el reparto que theGecko estaba buscando en su respuesta.