Dependency on EF

Apr 13, 2011 at 10:06 AM

Is it possible to somehow remove the dependency on EntityFramework? We use Nhibernate as ORM and we don't plan certainly to (up/down)grade to EF. All the stuff for EF is something we don't want in our solution.

Apr 21, 2011 at 3:52 PM

If you don't want all the EF "stuff" in your application, I have to guess that you do want the classes, controllers and views (and perhaps the repositories). If that is the case, then I should think you could consider using EF to generate these directly from your existing db and then edit the controllers/repositories to match the requirements of your own ORM. I can't say what that would involve but you as a user of Nhibernate would know what that looks like. Alternatively, you might try using Nhibernate with the EF generated classes and keep only the views. The connection to EF is through either an ObjectContext or the newer DbContext. Once that link is severed none of the EF "stuff' is of any further value.

Although there may be a number of reasons for staying away from EF, we have found that using "Customer.Order.OrderDetail.Product.Lot.CreationDate" is so much easier that creating complex sprocs, mutli-join queries or even LINQ. And it all comes for free by including the relationships in the model. Then again other advantages with your investment in Nhibernate, makes that a more difficult choice.  Either way you could still get some benefits out of scaffolding.

 

 

Apr 28, 2011 at 3:39 PM

Couldn't custom scaffolders be built to support building controllers or whatever against Nhibernate?

This would allow their continued use of Nhibernate while taking advantage of the goodness in MVCScaffolding.

Apr 28, 2011 at 9:27 PM

@gahayden Thx for your reply. We have our own mechanism based on DSL and T4 for classes generating, so there is nothing from EF that we could use. The reason I asked is that in our case (and I think there will be many others) we want to keep our solution clean and without unneeded packages. 

What I don't understand is why Scaffolding package is so dependent on EF. For me EF (and database area) is only one lego part from the solution. So I consider that as a optional package that can be installed.

Apr 28, 2011 at 11:43 PM

Ok. I thought I understood this pretty well but perhaps I missed something. If you use the command "scaffold controller" on your T4 generated classes, you should get a controller, views and yourProjectContext.cs file. Now none of the views have any connection to EF period, their only reference is to your class. So that leaves the controller, which is only connected to EF by the DbContext and although many of the controller methods make use of that context variable it could be replaced with whatever data connection or repository you'd prefer. In any case, at a minimum you should have a controller framework and the the various views.

Since the controller and views are based on T4 templates and you're already using T4 elsewhere, then isn't it just a metter of modifying the templates used by the MvcScaffolder to meet your needs?  Or am I still missing something specific to your domain?

May 4, 2011 at 4:45 PM

No I don't think MVCScaffolding is dependent on EF but it provides EF related templates. You can fully customize the templates. I think this is exactly why we use repository and service patterns. I recommend you customize repository/controller templates so that it uses NHibernate instead of EF.

But in order to make this process less painful and make code maintainable/testable, I would use service pattern as following

1.  customize repository template based on NHibernate

2.  create service scaffolder that can generate IXXXService interface and XXXService class, of course the service class only depends on corresponding IXXXRepository interface.

2.  customize controller template based on corresponding IXXXService interface.

May 4, 2011 at 9:28 PM

I understand the EF dependency in MvcScaffolding.  But the fact that T4Scaffolding depends on it is the problem.  This needs to come out.