[Opf3] ORM - a good idea?
On Codeproject is was asked the following question:
My answer was the following:
I can't agree on the blog entry about ORMs being the "Vietnam of computer science". There has been a lot progress in that area.
It's true that Microsoft has dropped the ORM Framework (ObjectSpaces) that was intended to ship with Whidbey. But that was because of other reasons. Microsoft is already using an ORM Framework in some of their applications (for example Exchange Server). They are creating WinFS for Longhorn (which hasn't been dropped, but only delayed) and then they were creating ObjectSpaces. That's three different ORMs - I guess (and I heard from people at MS) that this was to much for them. They didn't simply want three different frameworks for the same topic. They are now putting all their efforts in WinFS to create one framework for all.
Back to the progress: There has been a lot progress in the ORM field. Compare for example OPF.NET with Opf3? In Opf3 for a lot scenarios you don't even need to write SQL. Each storage class (each class that encapsulates a database) creates the SQL by itself, optimized for that storage.
Opf3 for example allows you to create very slim persistent objects: they are then serialized and remoted to any client. The overhead is quite little because the object consists only of those properties you want to load from the database. You may have 10 fields in the database and only load 2 of them and update only the two of them. Simply create an object that maps only to the two fields and you are good.
We are using OPF.NET with .NET Remoting in an application server. That server is doing all the loading from database, sending the objects to the client (up to 300 clients) and saving the objects back to the database. The clients are only modifying data in the properties of the objects; they don't even know that those objects came from a database. We didn't never have problems with that server. It's working very fine (also under heavy load).
My personal impression is that by using an ORM I'm a lot faster in creating database access and accessing the data in that database (like 50-90%). The ORM allows me also to implement design patterns a lot easier, because it gives me objects and not relations. Another benefit of ORMs is compiler time errors. If you use generic DataSets you don't get any error (during compile time) when you try to access a field that doesn't exist. With an ORM you get an error because you try to access a property of an object that doesn't exist (=> typos).
It's not so important that you may switch from one database to another by simply changing the storage class, it is more important to move the errors from run time to compile time. Another big pro is having a well designed class structure that allows you to add new features in a short time. Not being limited in the relational paradigma is also a very nice benefit. Why shouldn't you use all features of the object oriented model (for example inheritance) in your database objects when you use those features also in all other parts of the application?
What is your response to veteran developers who assert that object-relational mapping is the "vietnam of computer science", meaning, the amount of input effort far outweighs any benefits it may bring -- what is your thought on that?
My answer was the following:
I can't agree on the blog entry about ORMs being the "Vietnam of computer science". There has been a lot progress in that area.
It's true that Microsoft has dropped the ORM Framework (ObjectSpaces) that was intended to ship with Whidbey. But that was because of other reasons. Microsoft is already using an ORM Framework in some of their applications (for example Exchange Server). They are creating WinFS for Longhorn (which hasn't been dropped, but only delayed) and then they were creating ObjectSpaces. That's three different ORMs - I guess (and I heard from people at MS) that this was to much for them. They didn't simply want three different frameworks for the same topic. They are now putting all their efforts in WinFS to create one framework for all.
Back to the progress: There has been a lot progress in the ORM field. Compare for example OPF.NET with Opf3? In Opf3 for a lot scenarios you don't even need to write SQL. Each storage class (each class that encapsulates a database) creates the SQL by itself, optimized for that storage.
Opf3 for example allows you to create very slim persistent objects: they are then serialized and remoted to any client. The overhead is quite little because the object consists only of those properties you want to load from the database. You may have 10 fields in the database and only load 2 of them and update only the two of them. Simply create an object that maps only to the two fields and you are good.
We are using OPF.NET with .NET Remoting in an application server. That server is doing all the loading from database, sending the objects to the client (up to 300 clients) and saving the objects back to the database. The clients are only modifying data in the properties of the objects; they don't even know that those objects came from a database. We didn't never have problems with that server. It's working very fine (also under heavy load).
My personal impression is that by using an ORM I'm a lot faster in creating database access and accessing the data in that database (like 50-90%). The ORM allows me also to implement design patterns a lot easier, because it gives me objects and not relations. Another benefit of ORMs is compiler time errors. If you use generic DataSets you don't get any error (during compile time) when you try to access a field that doesn't exist. With an ORM you get an error because you try to access a property of an object that doesn't exist (=> typos).
It's not so important that you may switch from one database to another by simply changing the storage class, it is more important to move the errors from run time to compile time. Another big pro is having a well designed class structure that allows you to add new features in a short time. Not being limited in the relational paradigma is also a very nice benefit. Why shouldn't you use all features of the object oriented model (for example inheritance) in your database objects when you use those features also in all other parts of the application?
posted by Christian at 9:06 AM
0 Comments:
Post a Comment
<< Home