I've put together a short list of some O/R mapping tools for .NET and I was just wondering if anyone has had any experience with any of them and if so what your impressions are. Any other tools I've missed?
Commercial EntityBroker
http://www.thona-consulting.com/content/products/entitybroker.aspx Uses attributes/reflection. Nolics.net
http://www.nolics.net/ Uses attributes/reflection. Still in beta, launched in september. Looks very similar to the EntityBroker. Persistence.Net
http://www.objectpersistence.com/ Code generator. ORM.NET
http://www.olero.com/ormweb/ Code Generator. Pragmatier Data Tier Builder
http://www.pragmatier.com/ Code Generator. RapTier
http://www.2lkit.com/ Code Generator. TierDeveloper 3.0
http://www.alachisoft.com/ Code Generator.
Open Source NHibernate
http://sourceforge.net/projects/nhibernate Now seems dormant; attempting to create a .NET version of Java Hibernate. OJB.NET
http://ojb-net.sourceforge.net "OJB.NET is an object-to-relational persistence tool for the .NET platform. It enables applications to transparently store and retrieve .NET objects using relational databases. Ported
from OJB at http://db.apache.org/ojb" More can be found at:
http://sourceforge.net/In Development ObjectSpaces
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx Probably coming with SQL Server "Yukon"/Visual Studio .NET "Whidbey" sometime in 2004/2005; "Whidbey will also eliminate the
gap between data manipulation and programmatic object manipulation with ObjectSpaces. Complementary to existing data models, ObjectSpaces enable the manipulation of data transparently as objects." (I hope I'm not opening Pandora's Box with this one... ;-)
)
YOu aint :-) Hm - Nolics. Anyone heard of them? I had a look onto their site, and their tools eems capable, while their UI (what I can see) looks as unprofessional as possible (which is not seldom - somehow only very few tool developers get a graphics person
involved in making their UI's). They seem to go along with our current (old) way of requiring subclassing - not bad, to see that now that we abandon certain things as not scalable others are far enough to pick this up. What I really like is their visual databinding
setup - reminds me on OS/2 TCP: three pages of options for what other people do in a little dialog. Not sure I miss something here - our's is easier to use, but maybe I overlooked some feature. You miss Deklarit :-) Well, maybe you had a reason to leave them
out.
::Hmmm, I think they are all Toys :) Try to be original. One or two are toys - the others are serious ORM systems. Yes, I dont call all of these toys - some ARE ORM's that are feature complete enough to really carry this name.
> You miss Deklarit Well, maybe you had a reason to leave them out. Yes, never havint heard of them. ;-) But then again, they use DataSets and not domain objects so I'd exclude them anyway (http://www.deklarit.com/). I
really liked the interface though and the quick prototyping tool. (Looked at the online demo.) Something like that but instead creating domain objects would be nice(!). Perhaps something for a future version of EntityBroker? Anyway, I would certainly agree
that a lot of them are toys. I really hate the code-generation approach. It bugs the h*ll out of me having code generated that are not up to my standards of how code should look (answer = as good as me ;-) ). Is there a reason for generating code with 10 empty
lines right smack in the middle? In that respect LLBLGen is better because the code it generates looks pretty good and you can specify which notation to use (hungarian/pascal). But then again the Active Record-pattern (objects that persist themselves) isn't
really the ideal for complex domain models. Let's see what LLBLGen Pro does; LLBLGen Pro
http://www.llblgen.com/ Not yet released, no info yet on the site. Have heard sometime about a release this september.
::I really liked the interface though and the quick prototyping tool. (Looked at the online ::demo.) Something like that but instead creating domain objects would be nice(!). Perhaps ::something for a future version of EntityBroker? Hm, dont we have something
like this? Oh, sorry, you dont know our EntityBroker2003.1 Schema Designer yet, it is not public YET. If I had your email, I would send you some screenshots. ::I really hate the code-generation approach. We just switch over. But THEN - we dont generate your
code, only a small integration layer (what we currently do in the subclasesses). Basically your business objects inherit FROM a stub, and the stub is generated. We also generate empty business objects where they are missing (so the thing compiles), but then
- they are files with one namespace, one class and nothing in it (ready for you to override the fields). Well, our code is not customisable - but we support (in 2003.1) C#, J#, VB.NET, Javascript, Managed C++ AND ANY OTHER LANGUAGE YOU FIND A CODEDOMPROVIDER
FOR. I wonder why people generate code without CodeDom :-) ::Let's see what LLBLGen Pro does; As well as I know Frans, one thing is sure: it will propably not be a toy. He is pretty good at what he does - my main problem with LLBGEN was that it does not waht
I want. But what it does, it does well - so I am looking forward, too. I have seen some screenshots in his blog once, and it looks like our designer - done with nice looking controls. I am looking forward arguing with him :-)
:: But THEN - we dont generate your code, only a small integration :: layer (what we currently do in the subclasesses). Basically your :: business objects inherit FROM a stub, and the stub is generated I actually agree with you thona that this isn't a bad approach.
However, two comments: you'll no longer need the stub class with the new version of C# (I think its still a few years away from being released). It will allow us to divide a class definition into multiple .cs files. So one can be generated (with all the data-structure
and meta-attributes) and the programmer can create an additional file to extend the class with methods. This way, changing the data-model (which requires a re-gen) won't affect the class methods. I assume that file division/re-gen is the reason you came with
the stub/inherit idea, but perhaps you have reasons like Nolic for inheritance. Of course, I still perfer using the class definition as the basis for a data-model, though I can see situations where a seperate modeling-tool (with code generation) could come
in handy so I've considered offering both in my mapper. I liked the description of Nolics, right up to this sentance... "Nolics.net provides for a superclass from which all persistent classes must be inherited." Yuck. Super-class. I'll make my O/R Mapper (commerically?)
available next month. I'd like to charge for it, since most people only think a product with a stiff price tag is worthwhile, but I'm not sure if selling it will violate my employment agreement with EDS. So I may have to distribute it as a long-term trial
version.
::However, two comments: you'll no longer need the stub class with the new version of C# (I ::think its still a few years away from being released). This comment is wrong. I know, you thknk of particla classes. STILL - we need this one level of inheritance,
because the programmer can OVERRIDE the property methods. THis can not be done in a partiial class. See, the idea is this: * Class "Product", property/field Name. * The STUB has the integration code, plus all the attributes for the metadata. * The product
class can then overide the property and put validation logic in. So, partial classes does not change anything. We will still stick to the stubs :-( ::Of course, I still perfer using the class definition as the basis for a data-model, though I can ::see situations
where a seperate modeling-tool (with code generation) could come in handy ::so I've considered offering both in my mapper. Let me tell you some things here: * You are pretty alone with this. I was on your side (class model as base) for a long time, but hardly
any of our customers are. They prefer tools. * I am healed. Since I have the tool, I just can tell you - things are MUCH faster with it. Stil, our "Designer" basically generates the stubs with attributes. It is just so much mor econvenient to be able to work
with a little tool to set up the classes. ::I'll make my O/R Mapper (commerically?) available next month. I'd like to charge for it, ::since most people only think a product with a stiff price tag is worthwhile, but I'm not sure ::if selling it will violate
my employment agreement with EDS. So I may have to distribute it ::as a long-term trial version. From waht I read from you in the past you are on the verge of committing a crime. Did you not write your product as part of your employment with EDS? In this case,
you dont have anything you own - the copyright lies at your employer. Selling something you developped in your free time will not and never violate your employment agreement - well, it may in theory, but you have some legal protetion. Emplyoyment is not slavery.
BUT this means you developped it in your free time, not on your companies equipment etc. Fro mwhat I took from your other postings I would assume you dont own anything.
:: You are pretty alone with this. I was on your side (class model :: as base) for a long time, but hardly any of our customers are. They prefer tools. People will only dislike a class model if its unnatural, meaning lots of meta-attributes. As I've stated
before you only need them in a few special situations. The class definition by itself is good enough to stand alone. This IMO is the ideal. An alternative is to leverage off existing modeling tools (like Visio ORM or even XmlSpy's Schema Designer) and generate
code. The more the merrier and there's no reason even the oldest ones (like ERWin) couldn't be used. :: From waht I read from you in the past you are on the verge of :: committing a crime. Did you not write your product as part of :: your employment with EDS?
In this case, you dont have anything :: you own - the copyright lies at your employer. I work for EDS on government contracts with the state of OK, KS, and TN. From what I've read, these states own the copyright of anything I develop, and usually state software
is public domain, which is why I saw no harm in offering a trial version for free. :: Selling something you developped in your free time will not :: and never violate your employment agreement - well, it :: may in theory, but you have some legal protetion.
Employment :: is not slavery. BUT this means you developped it in :: your free time, not on your companies equipment etc. Well, I did develop it on my hardware, and I like to think the majority of it was written on week-ends which I consider my time. But in
truth I don't mind sharing profits with EDS. Its just they're not familiar with this type of tool and wouldn't know what to do with it. They got out of product development a long time ago. Anyway, I'll probably be notify my management of my intentions. As
long as I'm willing to share profits, I'm sure they'll be happy. They're are even groups within EDS that could help me market it, but again I'm cynical as to how much help EDS can provide considering their inexperience with this type of software.
Hellow all, Hope not make any mistake by putting this here, but here i go: About year ago or more i buy .NET Enterprise Development in C# from Matthew Reynolds and Karli Watson. My first tought about it after read is that while it seems not enough tested or
developed to get good feedbacks, there was plenty of good material to go with. But what make me post this is: While they call Line of business to their WEO, i would like to ear from you (Thona or SoulOfReality) about the way the author generate code, the way
they model Entity -> EntitySet etc. When i begin use it i feel some fault of liberty, but that seems to be with all kinds of code generators. I really apreciate some feedback, because while it seems a good approach, i can't find feedback about the book. Thanks
in advance
rearviewmirr...
Member
155 Points
31 Posts
O/R Mapping Tools for .NET
Aug 15, 2003 09:53 AM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Aug 15, 2003 11:23 AM|LINK
RussUK
Member
462 Points
93 Posts
Re: O/R Mapping Tools for .NET
Aug 15, 2003 11:31 AM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Aug 15, 2003 12:10 PM|LINK
rearviewmirr...
Member
155 Points
31 Posts
Re: O/R Mapping Tools for .NET
Aug 15, 2003 01:44 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Aug 15, 2003 02:12 PM|LINK
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Aug 16, 2003 08:03 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Aug 17, 2003 07:26 AM|LINK
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Aug 17, 2003 03:42 PM|LINK
João Ca...
Member
500 Points
100 Posts
Re: O/R Mapping Tools for .NET
Aug 20, 2003 10:44 AM|LINK