This project is read-only.

How to replace DAL?

Topics: Customizing Orchard
Mar 31, 2011 at 4:21 AM


If for some reason I want to replace current DAL that uses NHibernate with some custom one using Entity Framework for example, is there any guidance how to do it? Should I provide my own Repository implementation? Will it be enough?



Mar 31, 2011 at 4:33 AM

It would be very, extremely far from enough.

Mar 31, 2011 at 4:42 AM

Could you estimate how difficult would it be? How many modules would be involved? Well, is there any documentation related to this topic?

Mar 31, 2011 at 4:44 AM

Extremely difficult, requiring a very deep understanding of the platform, nHib and EF.

Mar 31, 2011 at 4:44 AM

I mean, to replace it entirely throughout the app.

Mar 31, 2011 at 4:51 AM

Thank you, that is pretty much everything I would like to know.

Just out of curiosity, so that means that NHibernate is very tightly integrated in core modules?

But I can still create my own module to query other data I need using any DAL I want side by side with current implementation, is it correct?

Mar 31, 2011 at 4:58 AM

Yes and yes. I'm not saying that it's impossible, to be clear, and it's actually kind of designed with something like that in mind, but trust me, you don't want to go there. As for your own module, sure, in principle you can do anything but you need to ask yourself if it's worth it and why you'd want to do it: there are good reasons to do something like that but there are also lots of advantages in not doing it.

Mar 31, 2011 at 5:00 AM

Thank you for replies.

Apr 15, 2011 at 6:29 AM

Hi Bert,

I want to use Entity Framework 4.1 and Nlayer DDD architecture <cite></cite>

I don't like the idea of locking in developers to use ORM features transparently like it is used here.
I understand that is done to help a general public. However to support other serious players in
SaaS arena some alternative ORMs should be introduced with total control of persistence.
I am currently exploring Orchard for a CMS platfrom to build an SaaS ecommerce application
that will be first built for on-premise delivery and later ported to Azure environment.

I would like to see some higher level prototypes and very simple examples of introducing EF 4.1 code first
approach from the main developers that know inside out of the Orchard framework.
If we have some introductory blog post, sample, idea that would help. Discouraging other ORMs is not productive,
because more serious developers will turn away and chose CMS that can support it or help developers get there.

 So Bernard I appreciate your effort in developing this great framework, but please, please provide us some insides in
incorporating EF4.1 which I believe will gain popularity in years to come and come very close to NHibernate.




Apr 15, 2011 at 6:50 AM

(not important, but my name is not Bernard)

I have no idea what you could possibly mean by "locking in developers to use ORM features transparently". We made the choice of nHibernate and it would not be a very productive use of our time to maintain compatibility with more than one ORM. The choice of ORM on the other hand does not surface much into Orchard APIs (although it's been argued by people smarter than me that you can't and shouldn't attempt to abstract the ORM away) so in principle it would be possible to replace nHib with EF. But why would you? Why would you reduce what you can do to the lowest common denominator? Why would you spend considerable time and energy maintaining two where you only really need one? What scenario does that address?

You an always attempt it but we're not going to spend cycles on this. At least not now.

Apr 15, 2011 at 9:56 AM

The real problem with EF CodeFirst is that it has no story right now when it comes to Migrations. It's something the EF team are discussing for future iterations, but until then there are Orchard features NHibernate is supporting that there is just no way to do in EF. Having used both I can say there are some things I just prefer about EF; it in general seems more friendly to .NET and especially Linq, and I felt performance was better (although this is just a hunch and I have no data to back that up!) But by the time EF gets around to addressing the migrations scenario, it really will be far too late to change.

Apr 15, 2011 at 1:15 PM



From what I understand from the last talk on Orchard, a developers can write some DAL code that is translated to NHibernate (Linq to NHibernate or NHibernate SQL variant) and something else takes care about mapping and persisting.
I am talking here about something quite different. If you can visit project and see how they layed out the layers of architecture you would see that there are DDD (application and domain services, Repositories,
Aggregate roots, value objects, Infrastructure layer etc) artifacts that I don't know how to translate to Orchard layers. I somehow see Orchard records and parts as dumb Active record architecture. If I want to introducte a rich domain/entity model
how would I use that. Then the choice of NHibernate or EF4 is irrelevant. I also think that NHibernate is a bit stronger (especially in migration arena).
So I want to hear more about introducing applications that will have multiple loosely or tightly coupled modules that can work together to create UI.
I work on a green project and will take up to a year to be production ready so by the time I finish Microsoft will further improve EF 4 so I firmly believe they will do it right.

Bert sorry about the name.


Apr 15, 2011 at 2:35 PM

From a quick look at microsoftnlayerapp, it certainly seems like a very interesting project.

The thing is, Orchard already has a very advanced modular architecture. It already allows "multiple loosely or tightly coupled modules than can work together to create UI" (this is what the core modules of Orchard are all doing).

If you want a CMS built on microsoftnlayerapp, there's nothing stopping you building one - but you have to build it for that architecture. It wouldn't simply be a case of "swapping out" bits of Orchard - you'd be implementing an entirely new system. You could try and borrow some of Orchard's concepts, for instance the dynamic content type system and shapes for template composition. But you really are talking about an entirely different project.

If that's what you want, go for it - it's certainly a project I'd be very interested in watching. On the other hand, if you want a flexible CMS that is working and usable right now - then you need to just start learning Orchard and accept the architecture as it is.

Apr 15, 2011 at 8:19 PM

Yes, and I would add that you could also make a compelling case for building a CMS on a NoSql database, which is a similar claim to the one you are making and that has its merits too. But as Pete is saying, that would be a different project. We had to make fundamental choices (and I'm insisting that those choices could not be avoided) and there is something arbitrary about the answers we chose, but it's better to stick to them because they are so foundational.

Apr 16, 2011 at 3:42 AM

Thanks Peta and Bert,

I was just trying to get your deep insight in Orchard to provide some technical possibilities, like Pete mentioned (dynamic content type system and shapes for template composition). If I can just get come clues of what types, interfaces to analyze that would help me a lot in trying to prototype something.
If Orchard shines in dynamic composition (as all CMS systems should), that shouldn’t be tightly integrated with a choice of DAL technologies. I could agree that for the core and supporting Modules and its UI elements one can still use NHibernate underneath, but for more complex systems that want to choose another DAL technology there should be some plug-in and integration point.
The idea here is to build a core DDD based architecture with a preferred IoC container, persistence layer and infrastructure concerns. If we assume that I can use already built architecture that include all of this (i.e microsoftnlayerapp architecture mentioned above), I want to build my system for multiple CMS systems (DNN, Orchard, Umbraco) in addition to a standalone product.
So I am coming from that end. I am not trying to change something, but to initiate the Orchard core team
to provide some integration points which will greatly open Orchard CMS to serious Module developers.
I don’t have a great ambitions at this moment to dig dipper into Orchard architecture, because I am building my core domain and basic MVC 3 Razor front end, and hopefully when times come to think about integrating my system with CMS systems, the first one to offer EF 4.1+ integration will gain my support.

I simply won’t give up and will similar questions to Orchard community. I can see me using Orchard’s current architecture to gain deeper knowledge and may find people with similar interest.

Thank you for your hard work on supporting community.


Apr 16, 2011 at 4:47 AM

There *are* integration points, and there is no coupling between the UI composition and nHib. So you can absolutely have a store that is based on EF and surface that as Orchard shapes. What you won't be able to do is integrate that deeply with the type system and content manager. That may be fine depending on your domain, or it may be a showstopper.