How many times we heard :
“I need to map this situation…bla…bla… Note: I can’t touch the DataBase schema.”
“I don’t like composite PK but I can’t change the DB schema.”
“I need to map this situation…bla…bla… Note: legacy DB.”
You can see phrases similar to those above in various NHibernate forums in various languages. The fact that questions are sent to a NH’s forum mean that somebody are developing a new .NET2.0 or .NET3.5 application using NHibernate with an existing DataBase (I’m hoping this is the only possible situation). If a company spent time and money to rewrite an obsolete application for sure is because it is needed.
Let me show another situation: In a new application the first base module was deployed in production. The team now has an existing application with an existing DB and is developing another module. In the second module we realize that some change is needed to the persistence we actually have in production. What the team should do ? Well…something normal for us is create a “migration step” for the DB. The same happen again and again in each sprint.
How much different is the situation when the existing DB is five, or more, years old ? (well… it is different but I’m not so sure that the difference is so big).
“I can’t change the DB because there are other applications using it”… my friend in this case the first step should be write a good service layer to serve “externals” applications.
Why, write a new .NET3.5 application, shouldn’t mean re-think the DB ? The DB is not a part of the old application ?
We are working in software, is the relational DB a piece of granite technology of the past century and nothing more ?
One of my preferred Mentor, illuminate me the way of ORM in these past years, is Scott W. Ambler. If you want help your DBA to come in the XXI century gives him some of Scott’s books. Waiting Christmas point him to this article and invite him to follow each singular link; perhaps you will win a friend.
Dear DBA we are not your enemies, we are both in the same ship.
Some DBA's are the Eliot Ness defending the legacy database as the "volstead act"... In other words defending what may be indefensible.ReplyDelete
Writing a service layer is only a solution if all clients can talk to the software layer. eg .Net to .Net, or Soap client to Soap Server or (in my case DCOM to .Net ServicedComponent). Yes, it's possible, but I'm having to translate all NH results (lists, sets) into variant arrays to transfer over DCOM to IDispatch clients. It's a lot of work.ReplyDelete
Sometimes, it's much easier not to change the database.
What about people who don't want to write a hand rolled data access layer to access a legacy database? Maybe they would like to use a well engineered quality solution, like NHibernate, to read from and persist to that database instead?ReplyDelete
Legacy databases exist and people (including myself) need to write software that reads data from them, regardless about how they feel about that, so that they can earn money.
Your Eliot Ness joke is clever but in my opinion it just shows a detachment from your users and a lack of understanding.
NHibernate can't fit all scenarios. If you have an untouchable legacy DB, even worst if it is not ORM oriented, you can choose other solutions more oriented to fit your needs (as for example iBatis).ReplyDelete