I'm astonished about quality of the content of this thread in a negative way. Are we discussing O/R Mapping Tools? There are three kinds of scenarios when developing an application. 1) Define the Relation Database Model first, generate the database, generate
the persistance classes. This is maybe the fastest development approach but not very scalable (learning curve of how classes are generated). This very popular approach also leads to bad OO designs from scratch but a good data model. Why? Becouse ER Modelling
follows a different paradigm then OO. Also the OO model is dependent on the database model. 2) Create the OO Model then generate the database. This averagely fast approach, leads to bad or not so good database models (not normalized). Also created a dependency
between the database model and the object oriented model. 3) Define the OO Model, define the Database model (if it does not exist), and establish and picked mapping. This is the slowest approach, but leads to the fastest and error prone code. Furthermore,
the database model is independent for oo model and vice versa. I honestly prefer the 3) but I understand that sometimes we don't have the time to do things properly. So any Excellent tool would provide support for the three scenarios (designers, UI interface
to estabish and picked mapping, ability to read XMI's and generate the database, etc). Also a good point would be how well integrated the graphical tools are integrated with Visual Studio, etc). How fast the peristance layer is, how are transactions handled,
what kind of strategy it follows for Lock management (Optimistick Locking with Object Revisions), etc? How Chaching is Handled? How are Dynamic Proxies handled? How does it support different environmens, such as ASP.NET applications, Windows Applications,
Distributed Applications, etc. This are all things that anyone planning to use or building a tool that is not a toy would need to worry about before even start discussing how anoying it may be describing mappings in XML by hand. Things that I don't see discussed
here. Demo's? Are fine, but give me a indepth Tutorial for the three kinds of scenarios with some benchmarks against standard ADO.NET approach. Best regards, Nuno Lopes
Someone posted ths following: :Also, OJB.NET might look nice, I doubt it will ever reach 1.0. I had a look on the tools that where mentioned in this forum. I strongly advise people to have a look on OJB.NET. Why, becouse honestly even in its version 0.* it
does a lot more then some commercial ones on Ver 1.0. This is the problem of open source tools, there is no product management towards commercial aspects. So comparing versions numbers is not always a good heuristic when it comes to Open Source Vs Commercial
tools from my experience. May I ask the person that wrote this, what is the basis for his assertion?
nbplopes, I find your remarks incredibly flawed, I'm sorry. Let's discuss them one by one, shall we? :)
There are three kinds of scenarios when developing an application. No. There are many more. For starters: developing an application doesn't start with the HOW, but with the WHAT coupled with a firm WHY, then the HOW on an abstract level and then HOW
on the detailed level. This can result in a tremendous amount of different approaches on that detailed level, and your remarks are focussed on just that, the detailed level.
1) Define the Relation Database Model first, generate the database, generate the persistance classes. This is maybe the fastest development approach but not very scalable (learning curve of how classes are generated). This very popular approach also leads
to bad OO designs from scratch but a good data model. Why? Becouse ER Modelling follows a different paradigm then OO. Also the OO model is dependent on the database model.
Since when is the paradigm you use to write your code in leading in the way your data is safely stored in a consistent way? You are not going to convince me an application written in VC++ using COM objects (for starters: not OO) targeting a database using
OleDb is 'bad' or 'not very scalable'. OO is just a way to write code, that's it. A relational database is something else. I'd like you to invite to read this slashdot posting, posted today:
http://developers.slashdot.org/comments.pl?sid=79683&cid=7039736. I then hope you'll understand what RELATIONAL databases are all about in relation to OO and why it is so important to set up the datamodel correctly, using tools and modelling equipment for
just THAT purpose, like a case tool or abstract modelling tool using NIAM or ORM (http://www.orm.net). I also fail to see why a good datamodel would result in 'bad' OO. There is no such thing as 'bad' OO, since there is no clear definition of 'OO' itself:
what shall it be, C++ or smalltalk? Java or smalltalk? Eiffel perhaps? Food for silly discussions between purists who believe what they talk about is what matters. Hint: that's not the case :). Also, why is generating classes from DDL not scalable? Can you
show me some examples where the scalability is hurt in any way (I'd be very suprised, because that would implictly imply using tables is not very scalable ;) )? When you do so, please also post your definition of 'scalability', because as with all buzzwords,
there are a lot of different definitions floating around these days :) The advantage of 1) is that the classes are totally data-independent. This means that you do not rely on any data value in the database to define the OO model. 2) and 3) don't do that.
2) Create the OO Model then generate the database. This averagely fast approach, leads to bad or not so good database models (not normalized). Also created a dependency between the database model and the object oriented model. This is not true. You can
create a complete normalized E/R model from a class hierarchy, although you need to use table values for class distinguishment. ORM (http://www.orm.net) and NIAM (ORM predecessor) can work with a hierarchy of supertypes and subtypes, and result in E/R model
definitions (with manual help to insert the supertype/subtype distinguishment, since that is totally semantic and as said, can't be modelled in DDL). So following the rules of ORM/NIAM, you can come to a model which is totally normalized (3rd or even 5th form),
starting by the class definitions. It requires work to create the correct class hierarchy mappings, since it relies on table values, nevertheless your claim is definitely not true.
3) Define the OO Model, define the Database model (if it does not exist), and establish and picked mapping. This is the slowest approach, but leads to the fastest and error prone code. Furthermore, the database model is independent for oo model and vice
versa. I honestly prefer the 3) but I understand that sometimes we don't have the time to do things properly.
I fail to see how the OO model is independent of the database model. The OO model is very tied to the database model, simply because you have to save class data to the database model, and thus follow the rules of the database model. This implies you have
to follow database integrity rules, and thus you can for example only save a given value in a given table if that value is part of a table row with a key, when that table has a key, constraints have to be respected etc. etc. All these things can't be ignored
simply because you think OO is the center of the universe ;). Also, try for once, to model a 4 layer class hierarchy in a database, WITHOUT using table values to class distinguishment. You can't. This implies that you require database values to establish class
instantiation. So where is this 'independence' ? I don't see it. The only true independent store of objects is a single table with 2 fields: an ID field and a BLOB field which holds the binary serialized object. All other database models are tied to the OO
model. And that's not a shame, why should it be. After all the application is requiring a database, so the database is part of the application. Oh! the application is tied to the database! :) Now, about your other remarks:
So any Excellent tool would provide support for the three scenarios (designers, UI interface to estabish and picked mapping, ability to read XMI's and generate the database, etc). Also a good point would be how well integrated the graphical tools are integrated
with Visual Studio, etc). How fast the peristance layer is, how are transactions handled, what kind of strategy it follows for Lock management (Optimistick Locking with Object Revisions), etc? How Chaching is Handled? How are Dynamic Proxies handled? How does
it support different environmens, such as ASP.NET applications, Windows Applications, Distributed Applications, etc. No, an excellent tool would allow YOU to do what YOU have to do in the best possible way according to YOU, which means that database modelling
can be done in a tool which is best for database modelling (visio is a good start, ERwin is also nice, but less abstract), BL design can then be done best with a modelling tool like any tool which can produce UML, and the glue in between is created by that
excellent tool. Remember: all the tools we're discussing here, do in fact the same thing: produce glue code so you can use that part of your application, the database, in a normal way from INSIDE your BL code (which you have to write yourself). HOW the tool
does that is really not important, what's important is that the tool lets you do what you WANT to do from INSIDE the BL code in the most easiest way. One example: you talk about lock management. ANY lock mechanism is bad, as long as it isn't done on the functionality
level, because whatever you choose will result in dataloss (see
here for details). So how can a tool which produces glue code you don't want to type in by hand, be of any help with locking on the functionality level when the functionality of your application is written in the BL classes, not in the glue code produced
by the tools? This are all things that anyone planning to use or building a tool that is not a toy would need to worry about before even start discussing how anoying it may be describing mappings in XML by hand. Things that I don't see discussed here.
I hope my users worry about totally different things than the stuff you care about, no offence. You see, application development is very complex, but when you analyze where the complexity is located, it's not in the glue code that glues your BL logic to
the datastore. It's in the BL logic itself: an order has been placed, how to update the inventory well, how to propagate the inventory changes back to all the running threads, check for legitimacy of the current customer, calculate discounts based on a complex
set of formulas which target 3 or perhaps more external machines... If you think the tools we're discussing in this thread should be able to generate that code, you are mistaken. SAP/JDEdwards, Peoplesoft etc. tried. And they failed in a long run, since those
systems are almost capable of doing what you're asking but still require a lot of work, but not programming.
Demo's? Are fine, but give me a indepth Tutorial for the three kinds of scenarios with some benchmarks against standard ADO.NET approach.
What's that, 'standard ADO.NET approach' ? datasets? Stored procedures called by hand-written code? DAAB using code? And you will believe a set of benchmarks placed on a vendor's website? :D
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
I have to agree with you, Frans. EVERY persisted object model is totally tied to the database. Having an object model and a database "independent" from each other is not reality - the objects have the properties to be persisted, and the database has to provide
fields for this. How can two models that are both reflections of each other actually not be dependent of each other? Delete field in the database, the object model WILL break. HAS to break.
Hey dudes, I'm a starting developer/student... at this moment i try to build a administrative/financial application .. by i want to know more about ORM before i decide to use it or not, does someone have links with good info (not a commercial-story in that
kind of: "USE our ORM" but a good review and info about the adv) Thanx:)
Bluemagics Weblog: "I'll always make your dark sky blue!"
::by i want to know more about ORM before i decide to use it or not, does someone have ::links with good info (not a commercial-story in that kind of: "USE our ORM" but a good ::review and info about the adv) Please explain what you want. ORM = Object Role
Modelling OR ORM = Object Relational Mapper (often written as O/R mapper) There is a ton of literature out there about how mappers work. I used the ambysoft website extensively (http://www.ambysoft.com/) - Scott Ambler has soem nice white papers out there.
I mean an O/R mapper.. I will read the white paper of ambysoft. thanx thona , i will post my questions after reading that whiter paper:) and i will take a look at your entity-broker. i have printed the user manual..
Bluemagics Weblog: "I'll always make your dark sky blue!"
I had a look on the tools that where mentioned in this forum. I strongly advise people to have a look on OJB.NET. Why, becouse honestly even in its version 0.* it does a lot more then some commercial ones on Ver 1.0. This is the problem of open source tools,
there is no product management towards commercial aspects. So comparing versions numbers is not always a good heuristic when it comes to Open Source Vs Commercial tools from my experience. May I ask the person that wrote this, what is the basis for his assertion?
Sure. The reason is simple: to create software that is appealing to a large group of people and is of top quality (and I mean the total package, not just the core) you require a hell of a lot of time and even more: you have to spend a lot of time on features
you probably won't require yourself as a developer. As a developer of various open source software (LLBLGen 1.x, DemoGL (openGL VC++ toolkit)), I know what it takes to create a tool that is useful to others. With that experience in the back of my head I said:
"it looks nice but I doubt it will ever reach 1.0", and I mean what I said. Just declaring your tool '1.0' doesn't make it 1.0 material at all. Is there a good documentation set? Is there a good designer/gui tool to take away the repetitive tasks? OJB.NET
uses xml files for the mapping IIRC. No offence, but try to do that for 100+ tables. It takes a lot of time, time you can easily save with a gui and some logic. I fully believe in the power of open source and free software (as in gratis) software. I also fully
understand what it takes to create succesful software that is appealing to a hell of a lot of people. Open Source as a term is not a ticket to succes per se (LLBLGen 1.x (the non-pro version, released last year) was a huge success, others, also OSS failed.
why?), it takes extra time and perhaps money to create that extra featureset, add that extra quality to the product that makes it worth using, because that's what matters: is it worth using, is it worth investing time into, does it save me time as others will
save me time or do I have to do a lot by hand even when I use this tool? It takes a tremendous amount of time to write GOOD documentation, to create a GOOD GUI. Full time development. This is an area where big players are making their business, if you think
you can win a lot of people over by just typing some code for a couple of weeks at night when you see fit, you won't be noticed, the result will not be up to par, because in the end productivity counts, not the pure-ness of a tool and how much it appeals to
purists. As I said before: O/R mappers are for generating the glue between your BL and the database, i.e. overhead. It's nothing special, it's dull stuff actually. If that process takes a lot of time using tool A compared to the time it takes using tool B,
tool A is not productive enough. End of story: the code produced by B is also allowing the user to develop his BL code, so that user is more productive, can do more in less time, saves money and can spend more time writing better software, more functionality.
I don't know, but I don't think it is a tough choice.
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
Frans said re: Inheritance ::I probably will add it in the coming year As a paid up customer of LLBLGen (comments in a minute) I'm interested to know how you'll approach this. I'm looking at the three patterns Fowler describes - Single Table, Class Table, and
Concrete Table Inheritance. My presumption is that, given the way 'pro' works at the moment through code generation, that the user will need to model the DB against some kind of - maybe one of the above - pattern in order for the inheritance to be mapped/used.
Given my limited intellect though it's entirely possible I've overlooked something. Or will you be changing the way that 'pro' (man it needs a friendly, roll off the tongue name) operates altogether? Anyway, just curious as to how you'll be looking to do that.
Meanwhile, bit of feedback on 'it': I realise all of you big gun O/RM fellas are slugging it out in here over issues I don't quite understand sometimes, but from a 'we knock out software in a fairly sizeable team, and our customers don't give a rats a$$ about
purity of system (even to the detriment of impending support costs which we'll never understand)' point of view it's a great product. We figured that (as so many have pointed out) it doesn't do everything we want, but then neither do most of the people working
here, so it's a welcome addition to the team. Production of the LLBL is embarrassingly fast too, and our database guys are very happy that it forces us to make a better job of database construction which tends to fall by the wayside when the customer is haggling
over a pretty UI but still needs everything finished by Wednesday. The pricing is crazy though. You should have a Pay Pal link so I can donate some extra cash equal to how we value the system. (Just kidding by the way...). But really, it's worth buying whether
or not you use it. Other things we liked - the concurrency thing and the transaction class. Simple to use. We couldn't think of a better name for it, and our slogan is "It does things a bit better than we do, and it doesn't moan about the wage." That's why
we're programmers, and not marketeers. Keep up the good work.
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 10:00 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 10:25 AM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 11:59 AM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 12:37 PM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 12:43 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 01:36 PM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 02:18 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 02:45 PM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 24, 2003 08:36 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
MishMash
Member
330 Points
66 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 08:35 AM|LINK