Jeffrey Palermo (.com) - All Comments

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Fri, 11 Jul 2008 13:02:39 GMT

This discussion can be continued here:

jeffreypalermo.com/.../making-it-easy-to-replace-nhibernate-in-five-years

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Garry McGlennon — Thu, 10 Jul 2008 23:44:01 GMT

Such a heated debate but also interesting too. For my two cents worth I agree with the concepts of the article and question anyone using features of an O/RM outside of their business/application layers. The general approach I take is one of service based whereby data access is service based at a CRUD level and business process level (two logical layers). Should we want to change the O/RM we'd only have to swap out the CRUD service layer (its the only thing that typically access the database). Now, having said that, this 'seperation' does have its drawbacks, namely that you can't access data as easily as you might like ie via an LLBGEN/nHibernate/Linq etc query from other layers. As you've abstracted this into data retrieval/storage interfaces, which have no understanding of the implementation. There are definately pros and cons for any solution, though I think the added abstractions will serve you better in the long run.

As a side note: Am I the only one who doesn't like the concept of DataContexts with O/RMs? Ie they don't play very well in service oriented architectures.

---------------------------------------------

Disclosure: I'm working on an O/RM mapper using a service based approach. Based on templates and the assumption you will change it!

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Ed — Tue, 08 Jul 2008 20:30:16 GMT

Late to the conversation here, but have a real(ish) example.

If you stick to using Interfaces, such as IRepository<TEntity> and implement concrete repositories such as NHibernateRepository<TEntity>, which has minimal bleed through, so you're practising strict separation of concerns and decoupling then exercises like this become easier:

A quick prototype app, which utilises ISubSonicRepository, suddenly 'evolves' into production and then in a blink of an eye needs to scale...

Just to keep you on your toes (and more likely to happen to all of us) the business decides to Persist People entities in Active Directory, of course augmented with database persisted details...(that hurt, hence my strong endorsement of at least trying to implement Jeffrey's suggestion.)

We recently outsourced an application the data is still available and mutable. However we have to use web services (some XML-RPC, some SOAP).

Therefore I think the above article is incredibly sensible because not only may you need to change O/RMs but you may need to chance persistence technologies entirely. LDAP is very different to SubSonic!

Don't learn the hard way like I did!

re: Realistically achieving high test coverage - MvcContrib

Donn Felker — Wed, 25 Jun 2008 14:53:28 GMT

Yulp, 100% agree.

I'm currently on a project that was developed test-first and I implemented CC.NET & NCover to break the build if it drops below 90% code coverage. So far, this code works excellent. The problems always seem to pop up in the areas where the tests ARE NOT. Failing early and fast has proven to be a great benefit.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Fregas — Wed, 25 Jun 2008 14:43:43 GMT

It depends on the application. For many applications such as small business websites we work on, the ORM will possibly outlive the website, i.e. the website will be rewritten or die before there is a need to switch out an ORM. For other applications with a longer lifespan, a new ORM may come along that works better, no matter how much homework you do ahead of time. Its not unusual for some applications to have a very long life--think of all the cobol apps that are still out there!

As an example, we have this one "small" website with a lot of database functionality that has homemade domain objects that are tightly coupled to a homemade ORM using ado.net objects like datareaders. I can't switch out the homemade ORM because all the persistence logic is mixed in with the domain objects. But man would i ever be more productive if i could plug in NHibernate or EF without having to rewrite the whole thing! So in this case, we really would have benefited from the previous developers loosely coupling the ORM from day one.

Another example was at my last job we had some apps using CSLA and one using LLBLGen and we were moving to WilsonORM. The swap was impossible without a rewrite, but desired by management in order to standardize on WIlson.

Most companies don't want to switch out their ORMs precisely because it would involve rewriting their whole application. But if it only involved swapping one layer and could provide standardization on the new ORM and enable more productivity, I think many companies would.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Wed, 25 Jun 2008 14:03:58 GMT

I do wonder why you would want to swap an orm. Because you start using another database? Nah, that can't be the reason; most mappers support the majority of databases and if not they most likely have an API you can implement. And if it really doesn't support it, you have done something wrong in the beginning.

Or because you reach technical/functional limitations of the ORM? In that case, you didn't do your homework correctly in the first place. You should already have looked at that kind of stuff when you decided what to use.

There is not a single company in the world who would want to switch their existing perfectly working applications which are using NHibernate to EF (Just an example), because it is "available" or "possible". Maybe in an application rebuild or a business decision to migrate fully to EF. But if you start keeping all that kind of things in mind, start preparing your applications for an nuclear warfare! It might happen!

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Fregas — Wed, 25 Jun 2008 13:35:51 GMT

My experience with O/R Mappers is that you'll have to rewrite at least some code if you decide to switch out SOME code, like querying, no matter how loosely coupled your application was written. As Jeffrey already mentioned, in order to switch out nhibernate he would have to rewrite his repository implementations, but thats it.

NHIbernate is probably the one mapper that allows the LEAST possible coupling to itself. I've used Wilson, LLBLGen, Nolics, and a few others. By far, NHibernate is the least intrusive to your code.

Frans, I'm going to pick on you a bit here, but please don't take it personally:

"This means that your own code will use and will be based on the characteristics provided by the data-access solution of choice...Also, the naive view on being able to swap out any o/r mapper you pick clearly shows you never gave it much thought: no matter which data access solution you pick, (so that means: whatever you choose) it will leak through into your own code"

Not so. If you layer your code correctly, you won't have to change near as much. I recently switched a small application from using WilsonORM to NHibernate. It took me about 4 hours, and most of that was changing queries to use HQL instead of OPath. Its true that if it was a bigger application it would have taken longer, but it would have also been easier had a layered things more the way Jeffrey suggests.

"Does it offer entity views on entity collections for easy in-memory filtering/sorting ? does it offer auditing/authorization? Which concurrency models are supported? Does it offer deep support for distributed systems so you don't have to babysit what's going over the wire?"

Those are all great features, but honestly, even for large complex applications, i don't often need all that. I can do an in-memory sort or filter of a collection using lambdas in .net 3.5 in just a few lines of code. I follow the Martin Fowler first rule of distributed architectures: "Don't distribute" unless there's a real need to. There are other tools to do auding and authorization. And in any case, do all these BELONG in an o/r mapper? Yes, if you rely on an ORM that has all these features and you use all of them throughout your domain objects, you'll be pretty tied that that ORM. But i see no compelling reason to do that. Those kind of things don't really belong in my domain model. If the ORM forces you to put them in the domain model, then something is wrong, in my opinion. But if you stick to the core of your application being POCOs and not being tied to the ORM, switching the ORM out really doesn't require a full rewrite.

It really depends on the ORM being used and how its used. Just because many ORMs require strong coupling between themselves and the domain objects doesn't mean all of them do. I think its a good idea to consider that coupling when choosing an ORM and whether or not you want your app to be tied to it 5 years from now.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:30:17 GMT

@Tim,

We don't de-couple NHibernate from our repository classes. We intentionally couple them to NHibernate. The core of the application relies on repository interfaces, which merely have implementing classes that are coupled to NHibernate. The core only depends on the interfaces.

To bring in different persistence, we would create new repository classes that all implement the same repository interfaces. By using the same automated test cases (APIs changed to support the new persistence technique), we can reliably ensure that the needed persistence scenarios are supported.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:27:22 GMT

@Paul,

At Headspring, we tend not to prefer frameworks. Rather, we enjoy using libraries. For instance, we hand-role the entire core of our application and then use libraries to keep from writing the following types of code: logging, data access, UI controls, caching, mocking, IoC. . .

We use a framework in ASP.NET, but that's our only compromise. The other libraries used are easily kept behind interfaces, and they don't bleed into the core of the system. These libraries include: Log4Net, NHibernate, various UI controls, Lucene.Net, RhinoMocks, StructureMap, Windsor.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:23:40 GMT

@Onur,

Isolating NHibernate _does_ work in practice, and I have 10 systems in production using NHibernate (for various clients) that illustrates how it can be done. I intend to release a reference application to help the community with this issue.

There are some conventions that _could_ bleed over if we aren't careful, but with a disciplined domain-driven design approach, it's not only possible, but quite easy to pull out NHibernate and create new repository implementations which persist in a different way.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:20:20 GMT

@Andy,

>"The blurring of Data Access and Business Logic isn't too evil after all."

The coupling of data access and business logic is still "evil". The context I'm living in is long-lived enterprise applications, not small, quick-hit applications. Therefore, these parts need to be de-coupled for maintenance reasons.

I am fully aware of the new technologies and APIs coming from Microsoft, but object-oriented principles and design practices are not altered by these new APIs. Consider them all and then choose which to use on small, trivial apps vs. which to use on long-lived enterprise apps.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:16:49 GMT

@Rick,

Discussing theory and being impractical is a bit dangerous, and I try not to give any guidance through my blog unless I have specific experience with it through real work. As the CTO of Headspring Systems in Austin, this is a topic we've put quite a bit of work into. We've worked with legacy systems, built new systems and continually upgraded and enhanced systems already built.

This scenario is real for us and practical. We don't have a lot of code around this (I also am leery about overengineering). We accomplish this loose coupling by interfaces and reversing the project reference so that infrastructure references core and not the other way around.

I intend to make a full application available to the community that illustrates the principles we follow as a company. I understand it's difficult for me to clearly communicate without concrete examples.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:13:28 GMT

@Frans,

I definitely did now write a comparison of O/R Mappers. Rather I'm trying to communicate that whatever tool is used, it should be used decoupled from the core of the application's logic. In this way, upgrades and eventual replacement will be possible without rewriting the entire application.

Since you bring up features, I'm sure LLBLGen has many more features than NHibernate. Given that, if folks bought products based on feature lists, our economy would be quite a bit more predictable.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Jeffrey Palermo — Wed, 25 Jun 2008 03:11:16 GMT

@Gary,

You are correct about the presentation layer and other infrastructure. My company also uses ASP.NET with MonoRail and is starting a large project with the MVC Framework. We consider that as infrastructure and likely to change, and we keep that away from the application core. We treat WinForms and WPF similarly.

I don't expect my clients to have to rewrite an application I delivered after only five short years. If they had to rewrite Headspring's work at five years, we would have a pretty bad reputation. We expect that system we develop will have a very long life. They will see infrastructure technology come and go, and the core will live on.

re: Objectively evaluating O/R Mappers (or how to make it easy to dump NHibernate)

Tim Scott — Wed, 25 Jun 2008 00:16:30 GMT

I guess de-coupling does get a little fuzzy. When I first used nHibernate, we had the idea to build a data gateway layer that would know about nHibernate. This layer would be ignorant to concrete business entities. The repository layer would know about entities and not about nHibernate. In theory we could then swap out the data gateway for something non-nHibernate.

This is not practical. As soon you start to write HQL in the repository layer, you have coupling. The repository must be aware of session...more coupling.

However, it surely is possible to achieve near persistence ignorance in the core business entity layer and also clients higher up the stack.

So +1 for the overall idea of the article. I just inherited a system that has Linq to SQL woven throughout (up to the UI.) Luckily it's a sort of prototype, and the boss has told me I am free to chuck it. However, I could have kept a lot more if the spirit of this article had been followed.