Repository Pattern + IoC/DI Injection Patterns

Nov 28, 2013 at 12:22 AM
Edited Nov 28, 2013 at 12:28 AM
I was going through the code and saw a lot of concrete references to the NHibernate interfaces (IService) in the method signatures. Wondering if there was a specific reason for doing so? Why not just use constructor injection with a lifetime management strategy in place?

Also, have you guys thought about adding a IRepository interface so that the storage/persistence layer is pluggable? As it stands now, even using IoC/DI it is directly tied to the nhibernate ORM. If you used a repository pattern you could plugin in things like EF or any number of NoSQL storage systems. Even SharpRepository project could have been awesome here as it's pluggable as well.

So, to get to the point, I am wondering if you guys would be willing to take a pull request if I implement this? Are you already working towards this or was this not part of the todo list?

I feel all of this would make this a serious contender in the .NET CMS realm and for guys like me that think Umbraco, Orchard, MojoPortal, DNN, Composite C1, N2, Community Server, SiteFinity, SiteCore, Kentico, Kooboo, etc.... are all too big and clunky and lock you into their way of doing things and have a large learning curve, etc... This could make a nice splash!
Nov 28, 2013 at 2:41 AM
Basically something conceptually based on this and it's component based architecture:

http://decoupledcms.org/index.html
Coordinator
Dec 5, 2013 at 9:24 PM
Sorry, didn't seem to have notifications set up on here and missed this being posted.

I'm not quite sure what you're meaning by using constructor injection with lifetime management, in as much as that is what's happening here, which is managed by the same Ninject IKernel as the rest of the app.

As for the IRepository part I'm all for making MrCMS more extensible but my concern about doing this specifically is twofold:

We've got to the point now where it's possibly too baked into the system to cleanly come out without significant work refactoring (although to be honest a lot of the core is probably overdue a once-over, as it's not been given a lot of love recently) as there are a lot of places where NHibernate's lazy loading of properties is used (and probably abused) in the name of the simplicity of domain, such as the UserProfileData Get generic methods here. The more I think about this it could just be that we maybe shouldn't be doing that though.

and

Adding the ability to completely switch out the type of data-store leaves me thinking that we'd probably not be making a system that plays to the strengths of either style of storage. That being said, I have little real-world experience with NoSQL, so my thoughts on that could be misplaced.

Have you got any experience with this, in terms of seeing any sort of difference with performance/efficiency when switching between stores?

If it's going to work just as well after it's done, I'm more than happy to accept the pull request, but I get the feeling that once you start to look at it, there are going to be lots of little bits that will be won't be solved. A case in point would be the installation/automatic creation of tables/fields as they're required or changes are made.

If you want to spend a couple of hours seeing how well it'll work out, and see what issues you run into removing NHibernate, I'm more than happy to discuss anything that you run into with while doing that, but my intuition is that it could turn into a bit of a nightmare.

Let me know what you think.