Hi, thanks for your reply. "Let's discuss them one by one, shall we? :)" - Your comments are between quites in this reponse. yes :) But first DISCLAIMER: I'm not a vendor, neither I endorse any software brand or product. I could be a customer of your company,
or lead my customers to buy your product. Yes I do work for a software company, but we do custom made software integrated with GIS. I will quote you a lot in this post just becouse in every single comment you did not understand me (g' that is bad for a vendor).
First we are talking about O/R Mapping not application development in general (remember the title of this thread?). So any comment that I make is in this scope (g' that is what I call like of focus, see next sentence). "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) When we are talking about o/R Mapping we are talking about the inner workings of an application, things are details for my customers (finance, health care, etc) but not for my company, we build
software. Unless I missed something, will a company like mine, or a group of people specialized in Software Development that may actually collect the benefits of you O/R Mapper, and so indirectly my clients. So decide who are your clients before telling a
prospect that he is talking details. 2) Within the scope of O/R Mapping and Relation Database I couvered all possible cenarios, Object Model (classes and associations) -> Data Model (Tables and relations), Data Model -> Object Model, Data Model <-> Object
Model (non automatic approach). Have I missed any possibility? "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?" Where have I stated anything like that? I have stated that? I used
the work generate as automatically generate (I do not generate code, machines do. I write code, capiche). Furthermore, maybe you missed my intended semantics for "scalable" in this context. I meant scalable Object Model and scalable Data Model while not compromising
"domain model" semantics. "RELATIONAL databases are all about in relation to OO ... " Your article states precisely the contrary (we have to fix the semantics of OO shall we, otherwise everything is OO). So if we fix the semantics of OO as a Paradigm the article
states the ER Paradigm is no isomorphic to OO Paradigm. So neither is all about the other. I "A relational database is something else." Look, I do software for more then 10 years quite succesfully. I have worked as a programmer, chief programmer, project manager,
product manager, as IT director, and now as a strategic consultant (yes, still I like to play with code and do analysis, now I code for fun, just that). So I do not need you to remind me what a Relational Database is. I have used the term Relational Database
Model, when I should have used ER Modeling. But abuse of wording is natural as behind Relational Databases is ER Modeling (human language can be challenging but if we focus we can understand each other). Furthermore you article uses this dictomy all the way.
Did you actually understood the article? The only reason why O/R Mappers work is becouse a comparison can be drawn between an OO Model and an ER Model. "then hope you'll understand what RELATIONAL databases are all about in relation to OO ..." I can only hope
that you actually understood the article. In the end it says precisely the contrary. Article - "These are not the same kind of thing, and there exists no natural mapping from one to the other. Anyone who tells you otherwise is selling something." If there
was a "natural" mapping then we could actually build a function such as, f(OO Model) = ER Model, f'(ER Model) = OO Model. In other wordsm your code generator would actually generate precisely the OO Model that "I need" out of the ER Model. This does not mean
that O/R Mappers do not work. Actually me and you being in this forum is becouse we agree that it works. "... that is 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)" Nothing like that. The parameters to analise the "quality" of an ER Model do have little to do with the parameters for analising the "quality" of an OO Model, although they have things in common. Normalization
is one of them. "I also fail to see why a good datamodel would result in 'bad' OO." I can clearly see that you did not understood the article, but more on that next. "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 :). " Sorry, mixing the notion of a paradigm with a language make me see
why you mention languages following/supporting OO Paradigm with the Paradigm itself. An ER Model is independent any language supportinghe Paradigm, so is an OO Model, capiche. "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 :)" Yes there is. But as I said if you focus on the discussing and get a hang on your wondering mind probably you understand the words from the context. Or if you do not understand,
ask before conclunding. That is what I do with my customers (or prospects). "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." What? In my book Classes are always data independent, independently of 1), 2) or 3). Furthermore, in what case I ever rely on a value in a database to define the OO Model? Give me an example so I can understand what you mean? "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." I guess you normalization issues or focused only on implementing the relational counterpart of a Class Hierarchy. You are telling
me you solved that, big deal others have - including me, but there is more then that. I give an example. I can have a model like this A - B - C - D A - C A - D Rule: If aC follows aA then aC follows anA. If aD follows anB then aD follows anA. Now a normalized
Data Model (ER) would be something like tA - tB - tC - tD The OO Model is tottally acceptable and is what is required. Why is it acceptable? Well, the semantics to establish class associations is bi-folded, data relationships plus object collaboration rules.
Now, data normalization is an ER thing as it concerns only with data relationships. A more specific example: The a Sales Order and its Order Lines is a data driven relationship. Wether the association between Sales Order, a Shipping Order, and Shipping Order
Receipt is process driven, so collaboration driven. So whatever nice generator class you may have, it could never infer my OO Model from the ER Model. "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." Considering that i'm not comparing a ER Model defined to support an eBank system with an OO Model to support the Space Shuttle guiding
system, of course, I must say that you are mistaken. So given a OO Model and an ER Model for the same problem domain, yes upon persisting an object the O/R Mapper must be smarter enough to figure how to map my objects and their links to tables in the database.
But my OO Model can be somewhat different (within the scope of that domain). Wether your product allows it to be that is another matter. For instance, let's say I'm faced with a legacy database built to support an Sales Order Management System. The stupid
"programmer/analyst" that defined and built the database did something like this: tCustomer [1:1] tOrder Rule: This relationship is required (FK's not null) You wonder why the hell he did that. Well, the O/R mapper does not wonder, he follows a predetermed
reasoning. So he will generate two Classes, Customer and Order. This when in fact he should just have generated just one Class, Order. You may think that this is silly, but you should have see that kind of databases that I have revered engeneered, no so long
ago, 6 years. Are developers now better then they ever were? I guess not considering that Bugs is still a hot topic. "All these things can't be ignored simply because you think OO is the center of the universe ;)." When have I suggested that OO is the center
of the universe? Is your tool the center of the universe for you? I guess not, so why this statement. "Also, try for once, to model a 4 layer class hierarchy in a database, WITHOUT using table values to class distinguishment. You can't." On thing is the ER
Model for the domain, another thing is OO Model for the domain, and you mentioned another thing, Meta-data to be used by the O/R Mapper to work. How you attach the intertwine you ER Model for the Meta-Data with the ER Model for the domain (my model) that is
a matter for you to solve, isn't 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." Clearly you don't have much experience working with a Corporation. Several application can be built over the same ER Model (this is quite common
actually, ask the IT of such companies). "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." I don't understand. First you say NO, then everything
that you say complies with my statement. I have not mentioned any tools, neither that all the tools need to be supplied by the O/R Mapper VENDOR. Haven't you said that you provide a GUI tool to at least facilitate the creation of the Mapping? How well is this
integrated with Visual Studio? If your product does not provide a Designer (which I think is a wise decision) how does it integrate with Together Control Center or RationalRose XDE for .NET? For you information XMI is a XML driven standard to persist OO Models
on a file in a device independent fation (Toguether Control Center does that through Export so do other OO Modelling tools). "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." Let
me tell you something. You avoided my the issues that I have mentioned telling me something like "Do not worry about that" our tool generates the code that you need. I have heard this kind of statements more then I should. I think that is why 4GL tools went
out of fashion. I guess that the same ideas are back again for some people to complete the circle. People do have a short memory. "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?" Do you know what Optimistic Locking right? If you know, then you should know that this is a standard strategy for "connectionless" database
access (that is the connection is freed as soon as data is fetched or persisted. This is the "minimial" form of locking that exist. This rises issues within the scope of mantaining the state of data out of the database in a consistent form. This rises write-write
issues that can be solved with Object/Data Versioning etc etc. So how does you O/R Mapper support this scenario? "I hope my users worry about totally different things than the stuff you care about, no offence." No offence taken. I guess I'm not in your target
market. "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..." Yes I know, but I also know
that Distributed Architectures complex and performance and Relational Databases and O/R Mappers, and ... Sorry if for me not to take your word for granted I need more speal that productivity driven semantics targeted to potential customer who have a short
memory, or a little experienced with this things. As for an integrated ser of solutions (designer, developer workbench, integrated O/M Mappinjg facility etc) have you had a look on Borland C%? They have a interesting approach to O/R Mapping called ECO, and
is fully integrated with Together Control Center (The best UML Modelling tool that exist), Borland Development Workbench, etc etc (fully .NET). The only draw back is that is not integrated with Visual Studio .NET, but if you are ready to use other vendors
development tools for .NET then it might be an option (I am not at the moment). "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?" You are the vendor. So you establish the basis for comparisons. I make my conclusions. Nuno PS: Sorry for this long post, but I did not had the time to write it shorter. I guess I have falled in the trap of actually answer it.
I just want to say that I have never suggested that LLBLGen is bad or good, or anything in between. I honestly don't understand why Frans so franticaly jumped on my case. "rats a$$ about purity of system" Neither do mine :) They want it to work now, fast, as
required by the problem to solve and with minimum maintenance costs (no bugs). I guess we are all on the same boat here. Nuno PS: You are the judge.
Hi thona, "EVERY persisted object model is totally tied to the database." Sure it is, but must be you OO Model? Just check my "Sales Order" example. Yes if my teams did not had to deal with legacy databases sometimes .... "How can two models that are both reflections
of each other actually not be dependent of each other?" That dependency should be only driven by the problem domain not the models themselfs. To understand why check my explanation. I'm an annoying prospect. Why, becouse I rather prefer ti discuss features
then benefits. Why? Becouse as a former Product Manager with some "strong" technical background I can discuss features, and deduce the benefits by myself. Nuno
::Hi thona, :: ::"EVERY persisted object model is totally tied to the database." Sure it is, but must be you ::OO Model? I did . UGLY as hell, frankly. As you said - legacy. Whow. Anyhow, I will have to think about it - right now we are a little more powerfull
than Frans (a lot actually), but harder to use (inheritance et al do not map to a fully automatic approach easily), and I am actually looking at what Borland has (which is quite interesting - though I seriously doubt the "best UML tool ever"). If yo can come
up with more funny usage scenarios and take them to our web boards, I will more than happy start architectural discussions about how to deal with them and what changes to do to the EntityBroker in order to accomodate them. THis sales/oder thing is scary.
Re: O/R Mapping Tools for .NET Hi Franse " "As a developer of various open source software (LLBLGen 1.x, DemoGL (openGL VC++ tcoolkit)), 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." So in reality the honest heuristc that drives versioning (there are other kind of heuriscs that can
be used) of commercial software is in no particular order: * Features * Quality * Customer Support (Documentation, etc etc) In Open Source is * Features, Features, Features * In good projects, Quality. * ?Customer Support? Read the forums if a forum exist
(learn by yourself). Due to this I think it it is unfair for both Commercial Software and Open Source to be compared by versions (The focus of their develpers is totally different). But you did that comparison when you stated that you doupted OJB.NET would
reach ever version 1.0. If one does this, its has to establish the semantics of version in both areas. "It takes a tremendous amount of time to write GOOD documentation, to create a GOOD GUI. Full time development." I would add, money. Documentation and support
are excellent reasons to go for commercial software. As I have told you, I was a Product Manager (for CMS System, really nice) and now I am Strategic Consultant, so I fully understand your statement from experience working both sides of the "fence" (Software
Vendor/Customer). But if the documentation provided by a vendor is not so good, etc etc, in the end it may be worst then a Open Source Product. I'm sure your product is well documented from the way you have answered to my post. But I'm not sure if the in its
core your product is as advanced as OJB.NET, probably is even more advanced. Anyway a straight comparison core-to-core would not harm none of the products. I just wish that we had for .NET something like Hibernate for Java. I would strongly advise it to a
team of smart developers. Another thing. A visual tool to construct mapping is a nice tool. But a tool that only supports inherintance by delegation, you end up writing more code then you would ever need to manage and update (OJB.NET only supports one strategy
to map inheritance rules to tables, one table for all objects, plus a tag, this is hardly averagly good too). Best regards, Nuno Lopes
I wrote: "best UML tool ever", concerning the new Borland UML Tool. Together Control Center. It is not originally from Borland as it recentely bought TogetherSoft. TogetherSoft was a company of Peter Coad (founder), previously named Object International. I
think Peter Coad is the new hot shot from Borland. As of "best UML too ever" is just a personal taste. I'm sure others will disagree. My intention was not in promoting Borland's Products or Solutions neither categorically stating what is best for others. Actually
Together Control Center is not part yet of Borland C#. The UML Designer you see there, I guess is not from TogetherSoft yet, although they say it is (probably is I have my suspecions that it is not, although highly speculative) Nuno.
::I just wish that we had for .NET something like Hibernate for Java. Working on it :-) Called EntityBroker, and for 2005 we will have a dEEP look into their feature table and add waht is missing. ::But a tool that only supports inherintance by delegation,
you end up writing more code then ::::you would ever need to manage and update (OJB.NET only supports one strategy to map ::inheritance rules to tables, one table for all objects, plus a tag, this is hardly averagly good ::too). I fully agree. I have some
apps here that have inheritance chains 5-6 levels depp (never adding data - just overwriting virual methods, specifying behavior, sometimes just addint attbrutes). Inheritance can be a great tool for a designer (which is why OO has it). And then you have remoting
and security - turning the mapper into something like EJB.
Hi Thona I understand the need to generate code. It makes all sorts of things easier for the O/R Mapper while not compromising performance on .NET world (CLR). But as you know .NET already as something called Code DOM that can be used to dynamically generate
and compile code. I think in the next version they will do this "feature" more flexible to control runtime byte code compilation. This in turn might be a way to implement lazy loading transparently (not requiring the use of Remoting Framework, Dynamic Proxies
and reflection, neither explicit Code Generation and subclassing). What I'll say next is highly debatable, so is just an opinion. I dislike code generators, specially when they are sold as a good thing for developers. They are not a good thing! But they might
be a necessary evil due to all sorts of reasons. Now if we can avoid it the better, this is my position. That is actually what Hibernate did. Hibernate since their early beginings had this vision (or something like this). 1) Yes reflection is "slow" but they
concluded that it is fast enough for a PersistanceLayer and most applications. 2) Createing Dynamic Proxies was slow, but they envisioned that it would get faster as JRE evolved "quickly". I think the same will happen with CLR if I know Microsoft a wee bit.
Actually their implementation of JRE was one of the fastest on the market. CLR and .NET being the new home jewel, I think they will not miss an opportunity here. 3) Bytcode compilation will also for sure be a reality soon for CLR, in ways much better then
it is for Java. So the Hibernate decided wisely IMHO, that they could actually skip source code generation and use reflection all the way. They predicted that in 2 to 3 semesters that it would be one of the best in Open Source (if not the best), if not against
commercial tool (feature by feature comparison). Meanwhile we will be easiest to use O/R Mapper (Magic!) without compromising flexibility. Nuno Lopes
Generated code. Bah! Only for simple O/R Mappers. :) Nuno, you are a welcome addition to this forum. I wanted to get your opinion on how I've designed my O/R Mapper (alpha now, beta next month).
http://home.comcast.net/~gabe.halsmer/default.htm The features I've included are... Alternate ways to define your Business Model * class definitions * Object Role Modeling * XSD Object <-> RDBMS
RDBMS <-> XML XML <-> Object Allow new data-formats to be plugged in. Conceptual Querying in an xpath notation (similar to ObjectSpace's OPath) Optimistic Concurrency LazyLoad (I don't like the way I've designed this though) ASP.NET Server Control for RAD
Web-Forms based on Business Model.
::But as you know .NET already as something called Code DOM that can be used to ::dynamically generate and compile code. Think it through, please, before stating things that are not applicable. First, even today there is CodeDOM - we use CodeDOM here to generate
the stubs the busines objects inherit from. BUT - this is of very limited use, unless you accept a separate dll just for the stubs, which we are not willing to. Otherwise I need the code in the compile tree. That simple. And just for the auto-generated stubs
(which contain hardly more than property get & set methods agaisnt our internal data container, plus attributes) adding another dll was seen as a very bad choice. ::1) Yes reflection is "slow" but they concluded that it is fast enough for a PersistanceLayer
::and most applications. Well, reflection is not "slow" Reflection is bad. Why? * The object knows nothing about whether it changed. Nice. Means I have to check, externally, all objects. * I need reflection rights. You may not know this, but this is quite
some right. I normally deny these rights in a lot of scenarios. Why should I require rights that I dont want? ::2) Createing Dynamic Proxies was slow, but they envisioned that it would get faster as JRE ::evolved "quickly". Ah, the java lie of moving. See,
the EntityBroker is not designed to be usefull with some runtime in the future. It is designed to be used NOW. NOW Mens with .NET 1.1. No chance of waiting. I could have waited for generics, partial classes and all the stuff - but i need something for our
projects - NOW. So I take what we have (.nET 1.1), learn from mistakes others do (hibernate) and came up with a solution that I think was easy to wok with. I erred, people wanted a designer and have nothing against benerated code, so we switch now. But Tthe
focus is not on thaving something that has no performance flaws in maybe a year when maybe the next version of the runtime maybe out, ut on having something NOW. Code Generators are, btw., a very good thing - IF the generated code is strictly separated from
the user code, or if they are a "run once" method. How could any UML tool work without a code generator? ::3) Bytcode compilation will also for sure be a reality soon for CLR, in ways much better ::then it is for Java. It will not be. I asked for method manipulation,
to be able to rewrite the bytecode of a method while it loads (which you can use in the java world). Nope, not planned. ::So the Hibernate decided wisely IMHO I consider this decision stupid. They demand rights that break object encapsulation JUST for the
sake of getting/setting data, and have to check every object every time. They also push all the responsibility for handling data binding events to the user. What is while with this? In the ENtityBroeker there is a lot that gets done in the base classes that
just reduces your code count. This may not be relevant to java people (after all, they are used to write repetitive code), but I prefer not to have to wire up my events for databinding manually, and to have a standardised way to see when my objects turn sour.
::They predicted that in 2 to 3 semesters that it would be one of the best in Open Source (if ::not the best), if not against commercial tool (feature by feature comparison). Meanwhile we ::will be easiest to use O/R Mapper (Magic!) without compromising flexibility.
Hm, Do I get this right, or are you showing a sign of Shizophrenia? I mean "They" predic that they would be one of the best, and "WE" will be th eeasiest to use? Ups. BTW - Open SOurce preople predict a ton of things. Like Microsoft going bankrupt next year.
This "we will be the best" is one of them. Hibernate is not near to thequality of the industry leader. Not near. Sadly. And - "we" will be the easiest to use. Hibernate? You make me laugh. I see a lot of nice things in Hibernate, and osme design decisions
which were done without thinking too much - using reflection is one of them.
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 11:32 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 11:45 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 11:54 AM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 01:13 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 01:40 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 03:43 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 04:03 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 05:50 PM|LINK
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 07:19 PM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 07:50 PM|LINK