Help! Must replace NHibernate.
-
I just received an email from the owner of the company I work for stating that I am no longer allowed to use NHibernate for anything! He says it's "too complex". This guy hasn't coded since classic ASP came out, and hes not involved in the development at all. I'm not sure why he needs to this, and I'm kind of freaking out.
Does anyone have any expierence with any other ORMs that are "less complex", or can anyone out there tell me if porting to linq to entities will work? I really want to avoid giving up the n-teired architechure (its been a tremoundous help to use here), and sure don't want to home brew my own ORM.
Help!
-
@NeonSnake said:
This guy is not involved in the development at all. I'm not sure why he needs to this
One option would be to say "No".
-
You're right. The guy is a very impulsive, I don't want to lose my job. I'll probably end up looking for a new one anyway. thx
-
Um, you're welcome... I think...
-
Why not say "OK, done," then don't change anything. If he isn't involved in the development then he won't be able to tell.
-
@NeonSnake said:
or can anyone out there tell me if porting to linq to entities will work?
If you really really had to migrate to another framework, I would stay away from Linq2Entities and the Entity Framework (EF3.5) in general until Microsoft release EF4.0 in spring next year. Linq2Sql might be a viable option but as from .NET4.0 Microsoft will start pushing EF4 as the data access technology of choice.If you have your data access organised using the Repository pattern and your DataContext encapsulated with the UnitOfWork pattern, you might be able to pull off this kind of switch. But I honestly wouldn't want to try it out without a VERY good reason.
-
I do like this idea, and I have thought about doing this. It's really a shame that I'm put in this position. I really should not HAVE to do this, and I guess if that's the environment I have to work in there's something wrong with that. NHibernate is wonderful tool, and if the man who hands out the paychecks takes a two minute look at it, says it's too complex, and enforces a rule that we can't use it-- this is not healthy place to be.
-
@bjolling said:
If you really really had to migrate to another framework, I would stay away from Linq2Entities and the Entity Framework (EF3.5) in general until Microsoft release EF4.0 in spring next year.
I strongly agree with this statement.
-
@NeonSnake said:
I just received an email from the owner of the company I work for stating that I am no longer allowed to use NHibernate for anything! He says it's "too complex". This guy hasn't coded since classic ASP came out, and hes not involved in the development at all. I'm not sure why he needs to this, and I'm kind of freaking out.
Does anyone have any expierence with any other ORMs that are "less complex", or can anyone out there tell me if porting to linq to entities will work? I really want to avoid giving up the n-teired architechure (its been a tremoundous help to use here), and sure don't want to home brew my own ORM.
Help!
How about simply asking him to give a few more details on his reasons than just "it's too complex"? Also explain to him how deeply that framework is integrated with your projects and how high the costs (both in money and time) of a replacement would be.
-
@bstorer said:
I also agree. EF3.5 is still rather buggy and cumbersome. We use it for a couple things here. But hopefully with EF4.0 it become more robust. As it stands right now its hard to justify using EF over NHibernate@bjolling said:
If you really really had to migrate to another framework, I would stay away from Linq2Entities and the Entity Framework (EF3.5) in general until Microsoft release EF4.0 in spring next year.
I strongly agree with this statement.
-
There is a solution to this. And its very simple: you make it very clear that the development team is happy to walk away and let him do the work. Or, take it up with a higher manager. Any manager worth their salt understands that a developer is going to have a higher likelihood of knowing what the hell is going on than this baboon.
-
@Indrora said:
There is a solution to this. And its very simple: you make it very clear that the development team is happy to walk away and let him do the work. Or, take it up with a higher manager. Any manager worth their salt understands that a developer is going to have a higher likelihood of knowing what the hell is going on than this baboon.
First of all, in this case, there isn't anyone over the boss's head, seeing as the order comes from the owner of the company.Ignoring that, neither of these is a very good idea. Both are immature responses that ignore the fact that this isn't some random person off the street; this is your superior who you have to work with tomorrow, the next day, and well beyond. In the best case, perhaps you win this particular battle, but at what cost? Threatening mutiny or going over your boss's head will only create new problems. The better strategy is to go on the record with your objections, explain why such a move is bad for the company, and hope you can sway the decision. If you don't succeed, either do your job or find a new one.
-
@bstorer said:
So, schedule a meeting between the entire development team and come to terms with the guy. If the development team as a reasonable argument, it should be no problem to get this guy to his senses unless he truly is ignorant of all things current@Indrora said:
There is a solution to this. And its very simple: you make it very clear that the development team is happy to walk away and let him do the work. Or, take it up with a higher manager. Any manager worth their salt understands that a developer is going to have a higher likelihood of knowing what the hell is going on than this baboon.
First of all, in this case, there isn't anyone over the boss's head, seeing as the order comes from the owner of the company.Ignoring that, neither of these is a very good idea. Both are immature responses that ignore the fact that this isn't some random person off the street; this is your superior who you have to work with tomorrow, the next day, and well beyond. In the best case, perhaps you win this particular battle, but at what cost? Threatening mutiny or going over your boss's head will only create new problems. The better strategy is to go on the record with your objections, explain why such a move is bad for the company, and hope you can sway the decision. If you don't succeed, either do your job or find a new one.
-
@Indrora said:
@bstorer said:
So, schedule a meeting between the entire development team and come to terms with the guy. If the development team as a reasonable argument, it should be no problem to get this guy to his senses unless he truly is ignorant of all things current@Indrora said:
There is a solution to this. And its very simple: you make it very clear that the development team is happy to walk away and let him do the work. Or, take it up with a higher manager. Any manager worth their salt understands that a developer is going to have a higher likelihood of knowing what the hell is going on than this baboon.
First of all, in this case, there isn't anyone over the boss's head, seeing as the order comes from the owner of the company.Ignoring that, neither of these is a very good idea. Both are immature responses that ignore the fact that this isn't some random person off the street; this is your superior who you have to work with tomorrow, the next day, and well beyond. In the best case, perhaps you win this particular battle, but at what cost? Threatening mutiny or going over your boss's head will only create new problems. The better strategy is to go on the record with your objections, explain why such a move is bad for the company, and hope you can sway the decision. If you don't succeed, either do your job or find a new one.
So you just backtracked on your entire original argument. Can't go over his head (and as pstorer mentioned, it's dangerous to play those politics anyway). Telling him the whole team is "going to walk" shows an adorable naivete. I'm sure the OP knows better than any of us how open to discussion his boss is on this point, and yet he didn't ask for inexperienced high school kids to come up with the perfect "zinger" for his symbolic firing, did he? He asked for technical solutions.
-
Thanks for all the suggestions.
I'm a strong believer that most problems between people is due to lack of communication. I have worked on a pretty strong arguement for retaining NHibernate which I'll have ready when I'm ready to face off with him. He's a very stubborn guy so hopefully I can get my coworkers to work with me to help persuade him. If not, well I tried and I'll have to evaluate my options for the future.
-
A few years ago at my former job, the CEO decided we should not use some app on the intranet because it was too complicated. We were to use excel and email.
We had a struggle similar to what you might be having. We documented ourselves, and made a case. After a few failed attempts at peacefull rebellion, we threaten to all leave and go mob unioninized on their asses. When we all got fired and got restraining orders. We burned the place down killing 13 and costing millions of euros in damages. It was pretty cool.
-
@fatdog said:
A few years ago at my former job, the CEO decided we should not use some app on the intranet because it was too complicated. We were to use excel and email.
I have to agree with your CEO: having a dedicated app to track siestas is overkill.
@fatdog said:
We had a struggle similar to what you might be having. We documented ourselves, and made a case. After a few failed attempts at peacefull rebellion, we threaten to all leave and go mob unioninized on their asses. When we all got fired and got restraining orders. We burned the place down killing 13 and costing millions of euros in damages. It was pretty cool.
Millions of Euros? That must have been one fancy taqueria.
-
@fatdog said:
We had a struggle similar to what you might be having. We documented ourselves, and made a case. After a few failed attempts at peacefull rebellion, we threaten to all leave and go mob unioninized on their asses. When we all got fired and got restraining orders. We burned the place down killing 13 and costing millions of euros in damages. It was pretty cool.
I believe you have my stapler?
-
Since NHibernate is open source, there is an obvious solution to your problem: Fork NHibernate, give it a completely new name (NeonORM would be a good start) and remove a little feature you have never used and will never use, so you can justifyably say "it's less complex".
-
NeonSnake, what's your problem? Object-relational mapping is a fundamentally wrong concept. I would gladly get rid of it and have done so in every project where I had enough weight.
-
-
@JvdL said:
NeonSnake, what's your problem? Object-relational mapping is a fundamentally wrong concept. I would gladly get rid of it and have done so in every project where I had enough weight.
I'm curious whether you're an idiot. What problem do you have with ORM, and with what do you replace it?
-
I've considered this. I'd call it SQLClients, tell him it's part of the .NET framework version 10.5, and that every other form of data acess tools have been depricated starting yesterday.
-
@bstorer said:
@JvdL said:
NeonSnake, what's your problem? Object-relational mapping is a fundamentally wrong concept. I would gladly get rid of it and have done so in every project where I had enough weight.
I'm curious whether you're an idiot. What problem do you have with ORM, and with what do you replace it?[-1 for quoting wiki]: "ORM is a technique technique for converting data between incompatible type systems in RDBMS and OO programming languages".
The operative phrase is "incompatible type systems". When designing an OO application of any complexity, you will leverage OO, something which is hard to represent in table structures. If you separate data and functionality too much, it may fit in a table but you will loose that leverage. Conversely, you may want to build an OO database on top of a legacy RDB. With ORM you end up with shallow objects reflecting the PK of your database. The problem is that either way you end up with a system that is the lowest common denominator of type systems with neither the acidity of RDBMS nor the flexibility of OO. Now "fundamentally wrong" doesn't mean it can't work in simple 1980's style forms applications, but who wants to use those.
Starting with EOF on NeXT as early as 1994, I was an early and happy adopter of ORM - it shielded my beautiful objects from those ugly tables. Moved to TopLink on Java in 1998 and later had brief stints with Hibernate. The latter after having already reached the conclusion: when in Rome do as the Romans and when in a database, speak SQL. Manipulate the data where it belongs and only transfer to and use in the application what you need. Which is often a dedicated single purpose object representing an aggregated data view. ORM will merely introduce many superfluous lines of code (*) compared to getting that straight from anonymous JDBC, ADODB or NET data objects. And ORM did never obviate the need to implement the data constraints on the DB: sooner rather then later other third party applications will share that data.
Refactoring ORM in various projects - including implementing business logic in SQL - has improved runtime performance and developer output considerably. It does require more than a passing knowledge of SQL though.
(*) XML declarations generated by a graphical OR mapper are, in the end, lines of code with their maintenance and all.@morbiuswilters said:
citation needed
http://www.codinghorror.com/blog/archives/000621.html
-
@JvdL said:
@morbiuswilters said:
citation needed
I read the title and closed the page in disgust. So ORM is just like a poorly-resourced war micro-managed by odious bureaucrats and inept politicians who are too afraid of "rocking the boat" to make a real committment to victory so instead drag the war out for years and years causing incalculable death and destruction?
Seriously, there needs to be a Godwin's Law for Vietnam to shut down historically-illiterate idiots who make nauseating analogies with no respect for the dead. Maybe Atwood's next article can explain how AJAX is just like the institutionalized mass-butchering of European Jewry.
As for JvdL: That's not a citation. Knowing Atwood, it's a poorly-written opinion piece on a technology he discovered over the weekend and doesn't yet understand.
-
@morbiuswilters said:
I read the title and closed the page in disgust. [...] That's not a citation. Knowing Atwood, it's a poorly-written opinion piece on a technology he discovered over the weekend and doesn't yet understand.
Actually, Atwood's blog entry is the five minute management summary of a more thorough piece by Ted Neward that he links to. It has the same poorly chosen and title and starts with a lengthy and needless opinion piece on Vietnam. According to the author, that tragedy was partly due to successive governments of both colors flip-flopping on the issue.
True or not, the analogy is that flip-flopping on OO or DB leads you to missing the benifits of one or the other or doing double work and usually all of that. And that, putting politics aside, is something I agree with.
More citations:
-
@JvdL said:
@bstorer said:
@JvdL said:
NeonSnake, what's your problem? Object-relational mapping is a fundamentally wrong concept. I would gladly get rid of it and have done so in every project where I had enough weight.
I'm curious whether you're an idiot. What problem do you have with ORM, and with what do you replace it?[-1 for quoting wiki]: "ORM is a technique technique for converting data between incompatible type systems in RDBMS and OO programming languages".
The operative phrase is "incompatible type systems". When designing an OO application of any complexity, you will leverage OO, something which is hard to represent in table structures. If you separate data and functionality too much, it may fit in a table but you will loose that leverage. Conversely, you may want to build an OO database on top of a legacy RDB. With ORM you end up with shallow objects reflecting the PK of your database. The problem is that either way you end up with a system that is the lowest common denominator of type systems with neither the acidity of RDBMS nor the flexibility of OO. Now "fundamentally wrong" doesn't mean it can't work in simple 1980's style forms applications, but who wants to use those.
Starting with EOF on NeXT as early as 1994, I was an early and happy adopter of ORM - it shielded my beautiful objects from those ugly tables. Moved to TopLink on Java in 1998 and later had brief stints with Hibernate. The latter after having already reached the conclusion: when in Rome do as the Romans and when in a database, speak SQL. Manipulate the data where it belongs and only transfer to and use in the application what you need. Which is often a dedicated single purpose object representing an aggregated data view. ORM will merely introduce many superfluous lines of code (*) compared to getting that straight from anonymous JDBC, ADODB or NET data objects. And ORM did never obviate the need to implement the data constraints on the DB: sooner rather then later other third party applications will share that data.
Refactoring ORM in various projects - including implementing business logic in SQL - has improved runtime performance and developer output considerably. It does require more than a passing knowledge of SQL though.
(*) XML declarations generated by a graphical OR mapper are, in the end, lines of code with their maintenance and all.@morbiuswilters said:
citation needed
None of your arguments really make sense. Of course I have been working with Entity Framework ("EF) so I don't know if Hibernate sucks so much that you don't like it. Or you have been using it in scenarios that were not well suited for an ORM
OO is very easy to map onto a database. A "Person" table represents a "Person" object. A "Person_Employee" table represents an Employee object inheriting from Person. The objects are just data transfer objects and therefore don't have any behaviour attached to them, except maintaining modification state and relationships with related objects. Works beautifully in domain driven design where you design the entities first and generate database structure later.
ORM mapping should not be used for applications that rely heavily on data processing. But in a standard "line of business" application, there is no performance gain or loss. Waiting for a user to click a button takes a lot more time than persisting an object to your data store. You don't want to speak SQL, you want your code to be independent from the datastore technologies.
You can never avoid mapping code. Either the ORM does it for you, either you have to write the plumbing code yourself (e.g. binding to parameters). I prefer the ORM to do that for me. Also EF includes nice designers so I never even have to maintain the mappings. I just update the Entity model and my entities and mappings are updated automagically
-
@bjolling said:
[...] OO is very easy to map onto a database. A "Person" table represents a "Person" object. A "Person_Employee" table represents an Employee object inheriting from Person. [...]
Are you trolling or were you sleeping when they explained the difference between isa and hasa?
-
@JvdL said:
Seeing your ad hominem attack I can only assume you're the one who's trolling. "isa" and "hasa" are both easily represented in a DB schema. I know because I have done it. Why don't you read up on EF4.0 a bit. Maybe Hibernate cannot do it but that is hardly my fault@bjolling said:
[...] OO is very easy to map onto a database. A "Person" table represents a "Person" object. A "Person_Employee" table represents an Employee object inheriting from Person. [...]
Are you trolling or were you sleeping when they explained the difference between isa and hasa?
First hit on google
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspx
-
@bjolling said:
Seeing your ad hominem attack I can only assume you're the one who's trolling. "isa" and "hasa" are both easily represented in a DB schema. I know because I have done it. Why don't you read up on EF4.0 a bit. Maybe Hibernate cannot do it but that is hardly my fault
First hit on google
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspxDid you read that? It is a clear demonstration that you cannot accurately represent an isa in a database other than by construing bad data models from a DB perspective.Which isprecisely my argument: using ORM you either create havoc in the DB or you create shallow objects in OO.
This Moses guy believes he did a good job by stuffing students and employees in one table, with one set of columns for one type and another set of columns for the other. A constraint like "every employee must have a hire date" that a payroll system would require is out of the question. Not to mention that in the real world, he'd never get past QA for creating a redundant DB for his applet. Way to go!
-
@JvdL said:
Not thoroughly enough apparently. I only read it until I saw him demonstrating the ability. I'm not denying you can create bad models in any tool and putting different entities in the same table is a bad idea. Now take his model:@bjolling said:
Seeing your ad hominem attack I can only assume you're the one who's trolling. "isa" and "hasa" are both easily represented in a DB schema. I know because I have done it. Why don't you read up on EF4.0 a bit. Maybe Hibernate cannot do it but that is hardly my fault
First hit on google
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspxDid you read that? It is a clear demonstration that you cannot accurately represent an isa in a database other than by construing bad data models from a DB perspective.Which isprecisely my argument: using ORM you either create havoc in the DB or you create shallow objects in OO.
This Moses guy believes he did a good job by stuffing students and employees in one table, with one set of columns for one type and another set of columns for the other. A constraint like "every employee must have a hire date" that a payroll system would require is out of the question. Not to mention that in the real world, he'd never get past QA for creating a redundant DB for his applet. Way to go!
Done properly, this would generate 4 tables:
- Person => PersonID, FirstName, LastName, PersonCategory (which is not needed)
- Person_Instructor => PersonID, HireDate
- Person_Student => PersonID, EnrollmentDate
- Person_Administrator => PersonID,AdminDate
The "PersonID" appears in all 4 tables so you can JOIN.
This database structure might not be perfect but it is good enough for my line of business application. How would you have modeled the DB? Like this:
- Person_Instructor => PersonID, FirstName, LastName, HireDate
- Person_Student => PersonID, FirstName, LastName, EnrollmentDate
- Person_Administrator => PersonID, FirstName, LastName, AdminDate
This you can also map to the same OO objects in the picture above, albeit with a bit more work in the mappings. So how would you have modeled this in the DB in such a way that I would not have been able to use OO fully in my code?
-
@bjolling said:
"isa" and "hasa" are both easily represented in a DB schema. [...] First hit on google: http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspx
@JvdL said:
Did you read that? It is a clear demonstration that you cannot accurately represent an isa in a database [...]
@bjolling said:
Not thoroughly enough apparently. I only read it until I saw him demonstrating the ability. I'm not denying you can create bad models in any tool and putting different entities in the same table is a bad idea. Now take his model:
[snip]
Done properly, this would generate 4 tables:
- Person => PersonID, FirstName, LastName, PersonCategory (which is not needed)
- Person_Instructor => PersonID, HireDate
- Person_Student => PersonID, EnrollmentDate
- Person_Administrator => PersonID,AdminDate
The "PersonID" appears in all 4 tables so you can JOIN.
Wrong again: this database model allows one person record to be related to an instructor as well as a student. That may be an accurate representation reality: a teaching assistent tends to be an instructor as well as a student. But is not an isa realitionship. In your OO model, instructor and student are two classes inheriting person and unless you use multiple inheritance, student and instructors are distinct objects and can therefore not be the same person.
@bjolling said:
This database structure might not be perfect but it is good enough for my line of business application.
If I got paid everytime I heard this I would be a millionaire. No wait. I am getting paid to clean up shit like this and I am a millionaire. Please continue.
@bjolling said:
So how would you have modeled this in the DB in such a way that I would not have been able to use OO fully in my code
There is no short answer to this question but I will give a few hints
- Make a data model for the database, regardless of any line of business application
- Put data constraints in the database or it will corrupt. Users don't care about our lovely applications.Our apps are just passing guests. Their data will continue to live long after our apps have been dumped.
- RDB models are not about structure - they are about data. Two tables with the same types of columns are not the same. Read up on normal forms and primary key candidates: they are about data, not structure.
- Don't waste your time modeling inheritance. Since DB don't give support (like polymorphism) for it, you're wasting your time
- Model DB's for law & order
- Make object interaction graphs and class models for your application domain.
- Objects are the same if they behave the same. This has nothing to do with their data attributes. A person and a corporation may be in the same class in a legal application but datawise they have nothing in common.
- Model OO for freedom & flexibility
-
@JvdL said:
True or not, the analogy is that flip-flopping on OO or DB leads you to missing the benifits of one or the other or doing double work and usually all of that.
I disagree. Properly done ORM gives you the benefits of both. I do tend to do the ORM by hand for more complex objects, but that's hardly a bad thing.
-
I'm with jvdl on this one - I find NHibernate's "one-size-fits-all" approach to building a data layer pretty dumb. It also is fiendishly hard to modify once the data layer has been created. I prefer to roll my own whenever possible. Its not that hard to do with VS's support for custom templates. Right now I have templates which create all my CRUD operations in SQL and C# (plus a couple of custom ones) from a single table name. If I need to modify anything, I just edit the generated SQL/C# code from my templates. It takes a little bit more hand-coding than with NHibernate, but the increase in flexibility is well worth it.
-
I vote for hand-rolled ORM. I'm never happy with the provided mechanism to retrieve multiple parent records along with all of their children in any ORM. This leads to a situation where you have to code exceptions for every combination of object sets that are needed in the application. If you haven't run into this before, an example would be getting all open orders along with their details and current on-hand stock for each. Retreiving one object graph at a time can be slow. EF4.0 shows promise, but I'm not exactly holding my breath.
-
Why dont use iBatis.. its easy to setup and use..
-
I know I'm a bit late on this, but if you're up for the challenge, you can try out LLBLGEN.
It's a horse's ass to learn, but once you get past the quirks of writing object-oriented queries (without a line of linq and inline pseudo-SQL), it's quite a relief to use it.
I prefer it over ANY ORM-mapper.
-
Not my fault that someone else rezzed this thread. I seem to have missed JvdL's reply back in december
@JvdL said:@bjolling said:
Why not? A real-life person could be represented by multiple instances of a child of the Person class. The limitations that you see have nothing to do with ORM. If you would use stored procedures or SQL queries, you would need to handle this case as well.<snip>
Now take his model:
[snip]
Done properly, this would generate 4 tables:
* Person => PersonID, FirstName, LastName, PersonCategory (which is not needed)
* Person_Instructor => PersonID, HireDate
* Person_Student => PersonID, EnrollmentDate
* Person_Administrator => PersonID,AdminDate
The "PersonID" appears in all 4 tables so you can JOIN.
Wrong again: this database model allows one person record to be related to an instructor as well as a student. That may be an accurate representation reality: a teaching assistent tends to be an instructor as well as a student. But is not an isa realitionship. In your OO model, instructor and student are two classes inheriting person and unless you use multiple inheritance, student and instructors are distinct objects and can therefore not be the same person.
@JvdL said:@bjolling said:
This database structure might not be perfect but it is good enough for my line of business application.
If I got paid everytime I heard this I would be a millionaire. No wait. I am getting paid to clean up shit like this and I am a millionaire. Please continue.
I've cleaned up a lot of shit as well. I always had happy customers that welcomed me back for more projects, so I must be doing something right. So what?
@JvdL said:@bjolling said:
So how would you have modeled this in the DB in such a way that I would not have been able to use OO fully in my code
There is no short answer to this question but I will give a few hints
* Make a data model for the database, regardless of any line of business application
* Put data constraints in the database or it will corrupt. Users don't care about our lovely applications.Our apps are just passing guests. Their data will continue to live long after our apps have been dumped.
* RDB models are not about structure - they are about data. Two tables with the same types of columns are not the same. Read up on normal forms and primary key candidates: they are about data, not structure.
* Don't waste your time modeling inheritance. Since DB don't give support (like polymorphism) for it, you're wasting your time
* Model DB's for law & order
* Make object interaction graphs and class models for your application domain.
* Objects are the same if they behave the same. This has nothing to do with their data attributes. A person and a corporation may be in the same class in a legal application but datawise they have nothing in common.
* Model OO for freedom & flexibility
So you are a "DB centric" kind of guy and I'm a "code centric" kind of person, which explains why we have different priorities. But that doesn't mean I won't create a proper database model.
You didn't answer the question by the way. None of your guidelines will prevent me from using an ORM tool to map your perfectly normalized tables to OO classes. I CAN map your tables correctly to OO parent-child hierarchies if I want to. I don't care if the DB doesn't know about this notion. Why would I? I'm using an ORM to avoid having to write all data access code myself.
@JvdL said:
But I will be able to do that easily - although again it has nothing to do with ORM but with a well thought-out architecture.
In practice, you will have a tool for say, student registration, that is widely applicable to learning institutions, and you want to sell it world wide. You'll not find a university that doesn't already have a database and you'll be hard pressed to find two that have the exact same database model. How will you map your application model objects to all these distinct DB's with ORM? You won't.
The classes I map to don't have behaviour. As long as we are in the data access layer, these objects are nothing more than data containers. So for every university in your example, I will regenerate custom data containers, e.g custom StudentData class.
In the business layer however, I work with the Student class. This is my domain entity that implements the business rules. So I need to add a mapping layer to correctly map the customized StudentData class to the generic Student entity. In the past I have done this mapping with custom code, but I've also used BizTalk mapper.This allows you to generate a mapping configuration file that your code can import, so you don't even need to customize your mapping layer
