Mit NHibernate.AspNet.Identity

Question

Ich versuche Asp.net Identität und NHibernate zu verwenden.

Ich habe eine neue leere Asp.net MVC-Website unter Verwendung von .NET Framework 4.5.1 erstellt und ich habe installiert und die Anweisungen für die Verwendung von nuget Paket NHibernate.AspNet.Identity wie hier beschrieben:

https://github.com/milesibastos/NHibernate.AspNet.Identity

die Account Klasse Standardkonstruktors beinhaltet die Herstellung der folgenden Änderungen am:

var mapper = new ModelMapper(); 
mapper.AddMapping<IdentityUserMap>(); 
mapper.AddMapping<IdentityRoleMap>(); 
mapper.AddMapping<IdentityUserClaimMap>(); 
mapper.AddMapping<IdentityUserLoginMap>(); 

var mapping = mapper.CompileMappingForAllExplicitlyAddedEntities(); 
var configuration = new Configuration(); 
configuration.Configure(System.Web.HttpContext.Current.Server.MapPath(@"~\Models\hibernate.cfg.xml")); 
configuration.AddDeserializedMapping(mapping, null); 

var schema = new SchemaExport(configuration); 
schema.Create(true, true); 

var factory = configuration.BuildSessionFactory(); 
var session = factory.OpenSession(); 

UserManager = new UserManager<ApplicationUser>(
       new UserStore<ApplicationUser>(session)); 

ich erhalte die folgende Ausnahme:

Kein persister für: IdentityTest.Models.ApplicationUser

Die ApplicationUser Klasse hat keine zusätzliche Eigenschaften IdentityUser (die für eine Entity Framework-Implementierung von Asp.net Identität einwandfrei funktioniert).

Kann jemand Vorschläge bieten, wie ich Asp.net Identität bekommen kann mit diesem NuGet Paket zu arbeiten?

Answer 1

Ich habe sehr viel mit dieser Bibliothek zu kämpfen, die ich macht die Frage, warum dies die empfohlene Bibliothek für die Verwendung von OWIN mit NHibernate ist.

Wie auch immer, Ihre Frage zu beantworten, können Sie den Code zur Verfügung gestellt, dass Sie von der Github Website bekam fügt NHibernate Zuordnungen für die Klassen der Bibliothek. NHibernate hat keine Zuordnung für ApplicationUser, es hat nur eine Zuordnung für seine Basisklasse. NHibernate benötigt eine Zuordnung für die instanziierte Klasse. Dies ist problematisch, weil Sie in der Bibliothek der Montage keinen Zugriff auf den Mapping-Code haben, so können Sie es nicht stattdessen die ApplicationUser Klasse zu verwenden, ändern. So ist die einzige Art und Weise daran vorbei, mit der Bibliothek, wie es ist, ist es, die ApplicationUser Klasse zu entfernen und die Bibliothek der IdentityUser Klasse. Oder Sie können den Mapping-Code von Github kopieren und versuchen, dasselbe Mapping für ApplicationUser zu verwenden.

Auch die Bibliothek Code und der Code, den er für die AccountController gibt nicht immer eine NHibernate Transaktion öffnen, so dass, obwohl die Bibliothek rufen Session.Save und Session.Update die Daten nicht letztlich in der Datenbank gespeichert werden. Nachdem Sie die Sitzung öffnen müssen Sie eine Transaktion öffnen und sie als privates Feld für die Klasse sparen:

transaction = session.BeginTransaction(IsolationLevel.ReadCommitted); 

Dann brauchen Sie transaction.Commit() nach der Aktion in den AccountController Oberflächen nennen Ausführung, so müssen Sie außer Kraft setzen OnResultExecuted:

protected override void OnResultExecuted(ResultExecutedContext filterContext) 
{ 
    transaction.Commit(); 
} 

Halten Sie dieses Beispiel ist stark vereinfacht, und in einer Produktionsanwendung Sie im Kopf müssen überprüft haben, Fehler in dem Sie statt Commit Rollback, wenn es Fehler gibt, und Sie müssen richtig nah an/von allem entsorgen usw.

Auch nachdem Sie diese Probleme gelöst haben, gibt es weitere Probleme mit der Bibliothek. Ich musste die Quelle von Github herunterladen, damit ich die Bibliothek ändern konnte, um sie zu verwenden. Es gibt mindestens drei weitere eklatante Fehler im Bibliothekscode:

1) In NHibernate.AspNet.Identity.Users:

public virtual async Task<TUser> FindAsync(UserLoginInfo login) 
{ 
    this.ThrowIfDisposed(); 
    if (login == null) 
     throw new ArgumentNullException("login"); 

    IdentityUser entity = await Task.FromResult(Queryable 
     .FirstOrDefault<IdentityUser>(
      (IQueryable<IdentityUser>)Queryable.Select<IdentityUserLogin, IdentityUser>(
       Queryable.Where<IdentityUserLogin>(
        // This line attempts to query nhibernate for the built in asp.net 
        // UserLoginInfo class and then cast it to the NHibernate version IdentityUserLogin, 
        // which always causes a runtime error. UserLoginInfo needs to be replaced 
        // with IdentityUserLogin 
        (IQueryable<IdentityUserLogin>)this.Context.Query<UserLoginInfo>(), (Expression<Func<IdentityUserLogin, bool>>)(l => l.LoginProvider == login.LoginProvider && l.ProviderKey == login.ProviderKey)), 
        (Expression<Func<IdentityUserLogin, IdentityUser>>)(l => l.User)))); 

    return entity as TUser; 
} 

2) In NHibernate.AspNet.Identity.DomainModel.ValueObject:

protected override IEnumerable<PropertyInfo> GetTypeSpecificSignatureProperties() 
{ 
    var invalidlyDecoratedProperties = 
     this.GetType().GetProperties().Where(
      p => Attribute.IsDefined(p, typeof(DomainSignatureAttribute), true)); 

    string message = "Properties were found within " + this.GetType() + 
             @" having the 
      [DomainSignature] attribute. The domain signature of a value object includes all 
      of the properties of the object by convention; consequently, adding [DomainSignature] 
      to the properties of a value object's properties is misleading and should be removed. 
      Alternatively, you can inherit from Entity if that fits your needs better."; 

    // This line is saying, 'If there are no invalidly decorated properties, 
    // throw an exception'..... which obviously should be the opposite, 
    // remove the negation (!) 
    if (!invalidlyDecoratedProperties.Any()) 
     throw new InvalidOperationException(message); 

    return this.GetType().GetProperties(); 
} 

3) In NHibernate.AspNet.Identity.UserStore: Aus irgendeinem Grund auf Zumindest beim Erstellen einer Benutzer-/Benutzeranmeldung über einen externen Anbieter wie Facebook wird beim Erstellen der Benutzer-/Benutzeranmeldung die Update-Methode anstelle von Hinzufügen/Erstellen aufgerufen, was dazu führt, dass NHibernate versucht, eine Entität zu aktualisieren, die nicht existiert. Vorerst, ohne genauer darauf zu schauen, habe ich in den UserStore Update-Methoden den Code der Bibliothek so geändert, dass SaveOrUpdate in der NHibernate-Sitzung anstelle von Update aufgerufen wird, wodurch das Problem behoben wurde.

Ich habe nur einfache Tests mit der Bibliothek ausgeführt, die nach meinen Änderungen funktioniert haben, also gibt es keinen Hinweis darauf, wie viele andere Laufzeit-/Logikfehler in dieser Bibliothek sind. Nachdem ich diese Fehler gefunden habe, macht es mich jetzt sehr nervös, sie zu benutzen. Es scheint, dass absolut keine Tests mit einfachen Szenarien durchgeführt wurden. Seien Sie vorsichtig mit dieser Bibliothek.

Answer 2

Ich hatte auch Schwierigkeiten, NHibernate.AspNet.Identity zu verwenden. Ich fand es war viel einfacher, nur meine eigene Implementierung mit NHibernate zu machen, die ich in einem minimal ausgearbeitetes Beispiel gedreht haben hier:

https://github.com/MartinEden/NHibernate.AspNet.Identity.Example

Sie Schlüsselteile sind eine einfache Implementierung von IUserStore<TUser, TKey> und IUserPasswordStore<TUser, TKey> unter Verwendung eines NHibernate Sitzung für Persistenz. Dann ist es nur eine Frage des Schreibens ein bisschen Klebstoff, um Owin zu sagen, diesen Code zu verwenden.