Just wondering if we could discuss the option to roll the objects to be purely poco... Tried to use NHibernate from the compiled *.dll, and since the objects don't override equals (maybe implement IEquatable()), NHibernate puked.
Rolled over to Entity Framework using the fluent mapping stuff, and I think I still need to run the mapping for the base models within the membership reboot dll.
leave 'em as is... just get rid of all the attributes, and roll over to the entitytypeconfiguration stuff. I'll have code for you shortly if I can get over a stupid error.
So, to do NHibernate, as I stated in the OP, we need to override Equals() or implement the IEquatable() interface on a few of the objects (those with compound keys). After our discussion on Jabbr, and wiping the proverbial egg off of my face, I think it'd be the only low-hanging fruit. I know that there are many that believe that data objects should contain zero business logic, but I am not one of them. So long as UserAccount is not sealed, I can always inherit from it and add my extra properties to the object and commit that to the table... we're still golden (I believe)
I'm also thinking that maybe MR could follow the same ideals as many of the other projects coming to market in the past 18 months by offering an IDependencyResolver which would allow end users to provider to MR whatever IoC container they choose to provide. This may give the ability, esp. for the plugin architecture that is in place for extensibility (all of the IEventHandler<> stuff) to be resolved as needed, instead of having to provide a singleton instance. Works out better for database connection lifetime management... leave that concern to the integration developer's discretion what the lifetime should be.
We could then potentially refactor the code to not be so dependent on automatically committing the objects to the database as soon as the Update() method is called, unless there is fear of the event pipeline doing work that may be invalid.
Ok, time for feedback -- I spent the entire day working on making MR have better support for custom user account classes and for custom properties on the user account class. While I wasn't able to pull off a pure interface based approach, I did end up with an ok approach where it's easy to add custom properties to your own user account table and the user account service is a generic class based upon your custom user account type.
This is prototyped on a branch: https://github.com/brockallen/BrockAllen.MembershipReboot/tree/poco
The customization sample is the best example of it in use: https://github.com/brockallen/BrockAllen.MembershipReboot/tree/poco/samples/CustomizationsSample
Please look over this and provide feedback and let me know if you think this is a move in the right direction and if it satisfies your requirements. Thanks!
@dealproc, Did you manage to get MembershipReboot to work with NHibernate? I am thinking of using re-mix to override Equals() and GetHashCode() without changing the base entity classes in MembershipReboot. But this is easier said than done so I wouldn't want to try it if there's a solution.
Using re-mix doesn't work as the mapping requires the actual entity class to override equals thus the proxy class is never used. I suggest allowing the entity classes to be pluggable to enable NHibernate composite ids. @brockallen, do you think this is a viable option or do you see a better one?
Yes, if you look at the code under v5 the class you use is now a generic parameter and thus you can do whatever concrete class you want/need.
Can all the entity classes be switched with custom versions? I find that the LinkedAccount class for example cannot be switched for a custom one without performing refactoring on the AccountService. NHibernate requires all persistent classes with composite ids to override Equals().
@calebkiage You may want to just implement the Equals() call, or IEquatable, and then provide @brockallen with a pull request. I did my work as a marathon session, and abandoned NHibernate because of it... i'm too far in to roll back to something else at this point, or i would have done so.
@dealproc I am thinking of adding Interfaces and then using generics to have all the entities pluggable for example have an ILinkedAccount, IUserAccount etc. I'll provide a pull request if I manage to pull it off.
@calebkiage yea, this has been another idea i've been toying with -- having interfaces to model the different "sections" of feature for MR -- 2fa for example. if you don't need it, then your user account class can not implement the interface. i'm back home end of this week, so i'll be trying to finish up all these recent changes i've been making.
@brockallen In that case maybe I should wait to see your implementation before applying modifications. I will implement the NHibernate persistence based on that.
Yep, I think that's a good idea. I've been traveling so I won't get back until tomorrow -- so please be patient while I get thru my backlog over the next few days.
Ok, this major rework has been checked in and all the samples now build. The customization sample shows how to defined your own UserAccount-derived class.
I've implemented persistence with nhibernate and i'm looking to add a sample. Problem is that i'm having issues with the Group and GroupChild classes. Is it possible to make the group classes abstract like the useraccount?
@calebkiage Yea, I can look into those -- open a new issue so we can track it.
I've created a new issue #204.