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.
Hi MishMash :) First, thanks for the kind words in your feedback :) I'm a theoretical educated guy, I like a solid reasoning as a foundation for a decision. If I implement inheritence, it will not follow Fowler. It will follow Nijssen/Halpin. This means
that it should be able to 'eat' a NIAM/ORM diagram or better: it should be able to reverse engineer an E/R model to an NIAM/ORM model (which supports inheritence of entities, by supertypes/subtypes). This is very complex material, but it can be done. When
I get that done, the inheritence is automatic. However, and I can't stress this enough, there is no need for inheritence in an O/R mapper, per se, simply because the E/R model isn't supporting inheritence, it only does on a 'semantic' level WITH data. When
you want to work data-independent, inheritence can't be implemented. There can be all kinds of tricks to implement 'inheritence' as in: map all kinds of class properties onto table fields, however these mostly work only in read-only mode, because saving an
entity class onto a set of fields scattered around tables is not possible. :) There are of course ways to implement inheritence by allowing the user to design the inheritence mapping and assume the user doesn't make a mistake. Now, making a mistake in an O/R
mapper is worse than you think, these mistakes are hard to track down. Besides that, LLBLGen Pro generates feature rich code which already has a lot of functionality to reach all the data you need from a single entity just by properties or walking relations:
what a lot of people try to accomplish via inheritence (which isn't inheritence, but they think they need it for this, don't ask me why) is for example 'customer entity has orders collection', this is already the case. In a couple of months when I have finished
the drivers for Oracle, MySql, Postgresql and Firebird/interbase (and DB2 if IBM starts shipping a final .NET driver), I'll look into implementing inheritence functionality just to make the purists happy, so there is one thing less to nag about LLBLGen Pro.
I knew from the start it would be a topic of debate, however as I've already discussed earlier in this thread: it's not there for a reason. :). No-one has showed me a way to model a 4-class hierarchy in an E/R model yet. No-one has also showed me a reason
why it is absolutely necessary (that's: mandatory) to have inheritence for n-tier applications, the applications O/R mappers are used for in the far majority of cases. It's a state of mind really: "I have a class hierarchy and how it's saved in that darn database
is not of my business". Well, as others also have pointed out: it IS important because the database IS part of the application. The DDL for the application structure and the data for the runtime instance. Because we have to live (still) with relational databases
(and believe me, I'd opt for a more flexibel model any day), that fact, the existence of a relational model, is part of the problem domain, and thus also part of the solution. :)
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 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
Sorry, I fail to follow this. Is A-D a relation between A and D? or is D a subtype of supertype A? Have you
ever tried to even MODEL a 2 layer class hierarchy in E/R? What you end up with is never as solid as the class model, it will always allow values that won't fit in the class model (as in: it will cause an invalid class model).
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. Again, I totally miss your reasoning. What is the theory behind this? Have you read my explanation about inheritence in database models earlier in this thread?
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). 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 mean, the FK from order to customer? or did you define an FK from customer to order (with an order field in customer PLUS a unique constraint on that field) (I guess so, because you say the relation is
1:1) You wonder why the h*ll 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.
One class, because of the 1:1 relationship? True, but then again, I can argue: the database is wrong: any 1:1 relation that is solely based on pk-pk relations should result in a table merge. However, there also should be a unique constraint on the FK field
in customer, otherwise the relation is m:1, not 1:1, and you CAN'T define 1 class, because an order can belong to 2 or more customers!
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.
Of course I don't think they are better now. The tools are better. 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?.
Yes it is a matter for me to solve, and I say it again, you can only solve it with data in the tables, you can't solely solve it with an E/R model alone. You want to 'capiche' me into a corner and believe me that it is possible, however you're mistaken.
You require data in the tables to establish class hierarchical mappings. End of story. If you think you can map a class hierarchy 1:1 on an E/R model, without requiring data, please, give Prof. Halpin a call or Prof. Nijssen, they will be very happy to listen
to what you have to say :) So, for the zillionth time: it's a decision you have to make as a toolvendor: do I use a pure E/R model as a base, or do I allow data in a database as well? Well, because I like correctness in programming and with tools that should
generate code that is used in other systems, I like them to be correct too, PROVABLE correct in fact. That's why I chose the data-independent route, the pure E/R model route. Because you can't map a class hierarchy solely on an E/R model, you can't create
a mapping set of a class hierarchy on an E/R model. This thus excludes inheritence (as Halpin/Nijssen already found out with their NIAM/ORM modelling technique). Others are free to chose differently and are free to throw mud at me on forums or 'capiche' me
around till doomsday because my O/R mapper lacks a given feature, at the same time totally missing the point why it lacks that feature and that it might be a good thing (tm) it doesn't have that feature. It also lacks a cache, you probably also will try to
lecture me around that the tool is crap because of that. Feel free to read the thread about O/R mappers and caches on this same forum for a discussion WHY it lacks a cache. I worked for 8 months, 16 hours a day on this tool and did everything with a reason.
If you think it still falls flat on its face because it doesn't appeal to your high standards, that's a bummer. However I'm too old to go into the same type of discussions I have had over and over again: this discussion is exactly the same between C programmers
who use C++ to add OO when they need it and OO purists who think people who write procedural code in C++ are incredible bad, while they totally forget that some logic simply
is better written in a procedural language than when it is written in an OO class hierarchy. (math library comes to mind). Then having the flexibility of a procedural language around while still having the power to produce OO code when you want it is
not ringing a bell at these purists. However the C developers using C++ for the OO when they need it are much more productive, because they don't have to use OO structures when they don't need them. It's the same with this. It seems that when an O/R mapper
isn't supporting inheritence (for a reason), it lacks something. It does not. Frankly, I don't think a developer will even notice it. The reason for that is that code produced by an O/R mapper is glue code. Overhead. It's code that is CONSUMED by the BL. O
darn, you have to do (myEmployeeObject.Type==EmployeeTypes.Manager) instead of (myEmployeeObject is ManagerEntity). However, there IS a difference: the people using the data-independent mapper (the one which sticks closely to the E/R model) can be sure the
code will ALWAYS work.
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#)
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). CodeDOM is flawed, unfortunately. First of all, you can't define all constructs with it, and second of all, it's not flexible: you have to program the codedom statements. This means, that people can't
change the code. With templates which use a lot of patterns, like LLBLGen Pro's templates do, you don't have that: there is a theoretic definition and a code emitter consuming templates which produces A (not THEY, A) projection of the merge of the definition
and the templates, which is the generated code. I fail to see why byte code compilation is required for lazy loading.
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. Hahaha :) You're funny :) You dislike code generators? So you write your own IL bytecode in a hex-editor, or better: the x86 asm which is produced by the JIT? The C# compiler is also a code generator. Using a GUI to design a DEFINITION which
is then generated in a block of code (but can also be compiled directly to IL if you like) is the same as writing the C# statements and compile that. Code generators are a good thing, the best thing ever happend to developers. The reason for that is that programming
is not source-code related, it's algorithm related. This means that the algorithms created by the programming process have to be translated into sourcecode. This translation is also known as typing. :) Typing is a crappy method to translate algorithms into
sourcecode or better: translate algorithms into runnable code. My ultimate dreamtool would be where a programmer simply designs the application logic in an abstract fashion and the code to run it is generated. Prototypes of these exist actually. And I predict
within 30 or 40 years, these tools will be the majority of tools used by 'developers'. Saying code generators are bad is not saying what you REALLY wanted to say I think: code generators which generate inflexible, not-correct transformations of teh definitions/algorithms
are bad. And I agree. But these are not representatives of the group of 'code generators' which can be very benificial. On the contrary. LLBLGen Pro uses partly generated code and partly runtime classes. The generated code is meant to customize the runtime
classes using patterns (strategy mostly, some factories). So in fact, you have generic code which is customized using generated code. How flexible do you wanna get? it requires NO typing, and still you have generic code and a little code generation. (which
is done using templates, also flexible).
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#)
thona :: 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. OMG, thona you are so dense it pains me to read your posts anymore. This is exactly what Nuno said. Whenever someone posts a message "A is true". Thona replies... "No! You are wrong! Because
A is true!" Thona must have been taught as a child that a load boisterous tone matters more then being correct. Frans :: I can't stress this enough, there is no need for inheritence in an :: O/R mapper, per se, simply because the E/R model isn't supporting
inheritence Then you've abandoned object modeling for ER modeling. This is not a step in the right direction Frans. :: I'll look into implementing inheritence functionality just to make the purists happy You'd make a lot more people happy then purists by supporting
an OO model design. We're all C# programmers here. I for one of had my share of ER modeling and am happy to leave it in the past. :: Hahaha You're funny You dislike code generators? ... :: Code generators are a good thing, the best thing ever happend to developers
You're beyond help Frans. I realize it would be hard to convince you why code-generators are not God's Gift to Programmers, considering you've spent so much time developing a mapper based on it. I was in a similar boat myself. A fellow architect (a man I hold
in high regard) disapproved of my mapper's code generation, and I was quite defensive about it at the time considering how much effort I had poured into that tool. But when I heard his arguments for reflection, I slowly become convinced it was a better approach.
Its not that code-generation doesn't work, its just messy for the end-user. But like I said, you won't be convinced of this until you try reflection in your mapper.
Hi all, Before replying to any post I'll just want to make a personal remark. People tryied to insult me several time here in one way or another and I honestly fail to see why. For instance: Thona wrote in a post: "Hm, Do I get this right, or are you showing
a sign of Shizophrenia?" Just becouse I talked well about another ones vision. A product my teams have used and has a backup of a lot of user. A product that is not even a contender to any vendor here as it is not in the same technological space, etc etc.
This is not reasonable behaviour if we actually want share points of view, make questions, give suggestion, build confidence etc. Maybe its a question cultural differences as I live in Portugal (Sunny and warm, not so stressfull). After 15 hours of work, I
want to sit down, relax, learn and share. I'm not being paid to be in this forum to put up with this. Also there is another behavioural pattern here that is a wee bit annoying. People tend say "NO" to certain that I have written, but then when they explain
why I'm wrong its actually confirming that I'm right (I'm not saying that it happens always, neither that I'm right, but if you say "no" ... ...read it through, please, before stating things that are not applicable or are just confirming what I've written.
But probably it is my fault as my mother language is not English, I'll have to try and learn more to fix any missed understandings. Take it easy, Nuno
Hi Thomas, As I have said: "What I'll say next is highly debatable, so is just an opinion." Your points about Reflection are good ones. "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." Nice, but I don't recon your edge here, if you are counterposing Hibernate Teams vision. "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 ..." Strictly separated suggests that I may have to play with it. So every time I have to play with generated code it breaks the generation process. So the benefits of code generation are denied after that. Furthermore, I have to learn
how the code works, mantain it etc etc This why I don't like code generators, another build step, It can break my UML design as I'll have to subclass from a generated class (not the model) etc etc. "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)" Some O/R tools actually free you from writing a lot of repetitive code, without making you refer to generated code.
But its all abou compromise, win some things, loose some. "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." Can you provide me with an example for this an example of what
you don't prefer? "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?" As I have said, I'm not English (so some problems using the language) and
believe it or not I'm not in Hibernate team is not WE but THEY (stand corrected). Take it easy! Best regards, Nuno
Hi Frans, "Sorry, I fail to follow this. Is A-D a relation between A and D?" I used "-" for association in the OO and for relationship in E/R "Have you ever tried to even MODEL a 2 layer class hierarchy in E/R? What you end up with is never as solid as the
class model" Yes it is never as solid, but its workable considering one choose the mapping strategy to be applied. "it will always allow values that won't fit in the class model (as in: it will cause an invalid class model)" That is why I like to work from
the class model to the data model, not the other way around. "Again, I totally miss your reasoning. What is the theory behind this? Have you read my explanation about inheritence in database models earlier in this thread?" Forget class inheritance for a moment
Frans. Think about object assocition (not data relationships). Imagine you want to model this (this is actually the FDD process): "A Software Project progress along 4 phases. First you the over all domain model, then build a feature list, then plan by feature,
then iterate over design by feature / build by feature" Project [1:1] DomainMOdelling [1:1] BuildFeatureList [1:N] DBF [1:1] BBF Now suppose this rule: You can only assign a Chief Programmer to the BuildFeatureList that is a Project Member. Project [M:N] Project
Member ChiefProgrammer [1:1] ProjectMember BuildFeatureList [M:N] ChiefProgramer You may be wondering why an M:N relationship between BuildFeatureList and ChiefProgrammer. Simply CP is a role of Person. You for instance, can be a Chief Progammer in several
project, and can participate with that role on seveal BuildFeatureList Phases. Suppose that the current model above actually can be transalated to a normalized data model. Table_Project ........ Back to the model, Now the problem is in implementing that rule.
At the moment BuildFeatureList as no idea that is within the scope of a Project (no association beween it and the Project, neither it can ask anyone as it only knows it is happened after DomainModeling and before several DBF's. So lets give it the knowledge,
Project [1:1] BuildFeatureList Bang, un-normalized data model. I don't have time to explain why this is the best solution (Streamlined Object Modeling is a very good book about the subject. Also make Goolgle search for "Domain Neutral Component" or DNC and
Coad) Now ther a feature that a O/R Mapper could provide to solve this. This considering that the it fully supports and endorses going from Object Modeling to Data Model in a hand picked mapping approach. The mapper could allow the mapping of an attribute
to be actually a JOIN. That is: BuildFeatureList.aProject to be the same as BuildFeatureList.DomainModelling.Project I'll let the other questions regarding the relations for you Ok? If not please mentioned it again and I'll explain. But seriously it not a
matter of where the FK is "Yes it is a matter for me to solve, and I say it again, you can only solve it with data in the tables, you can't solely solve it with an E/R model alone. " Never said that can solve it differently, neither otherwise. "You want to
'capiche' me into a corner and believe me that it is possible, however you're mistaken. You require data in the tables to establish class hierarchical mappings. End of story. If you think you can map a class hierarchy 1:1 on an E/R model, without requiring
data, please, give Prof. Halpin a call or Prof. Nijssen, they will be very happy to listen to what you have to say :)" I have already asnwered this. I don't need a perfect mapping, but a workable. As you have stated, there no proper way to map it, but there
are several strategies (use one table and a symbol, use two tables and a relationship (one with a symbol and the other without), etc. Yes for this, my ER Model will no longer be normalized it may happen that someone put values in those tables that are invalid
by going directly there without using the application. "That's why I chose the data-independent route, the pure E/R model route. Because you can't map a class hierarchy solely on an E/R model, you can't create a mapping set of a class hierarchy on an E/R model.
This thus excludes inheritence (as Halpin/Nijssen already found out with their NIAM/ORM modelling technique)." There workable mappings, but you may choose to ignore them. But for perfomance reasons you need to allow the developer to choose the best hirarchical
mapping strategy for the objects in question and the application itself. That is, you need to allow the developer to tailor the mappings in a hand picked form (not automatic). "Others are free to chose differently and are free to throw mud at me on forums
or 'capiche' me around till doomsday because my O/R mapper lacks a given feature, at the same time totally missing the point why it lacks that feature and that it might be a good thing (tm) it doesn't have that feature." Look Franse, I have never said that
your product is bad or good or anything in between. Or if it would bad if it does not have this and that feature. Neither I want to put you in a corner, but it seamed that you wanted to do precisely that to me when you answered to my first ever post in this
forum. Totally disregarding the point I was trying to make, jumping to conclusions about my expertise, etc etc. "However I'm too old to go into the same type of discussions I have had over and over again: this discussion is exactly the same between C programmers
who use C++ to add OO when they need it and OO purists who think people who write procedural code in C++ are incredible bad," It seams that the word Bad or Good rules here. I don't like either words, becouse they tend to polorize an idea or opinion while blurring
the actual mindset used for a decision. I don't think that I have used any of those words. "It's the same with this. It seems that when an O/R mapper isn't supporting inheritence (for a reason), it lacks something." Yes it does lack something. Is up to the
client to decide how important that is. Personally I like a model as flat as possible but I need inheritance too to scale the framework with new classes and bahaviour. Also I use the domain models to comunicate with clients and developers. Domain models that
I dont want modified if the customer says that is correct, and I don't want them to have to sync by hand the model with the code and vice versa. When I use the term "I" I'm refering to myself or any developer in my company. Look, I've never said that OO is
better then whatever. But we are talking about O/R. The reason why I want to use O/R is beacouse I want to manipulate objects (units of data and behaviour), not datasets ot records (Also I have use for UML) while still using a RDBMS. Also I don't want the
burden of developing a layer between the database and the objects. Also I want to use UML no ORM, etc etc. But that is me. I came to this forum looking for O/R Mappers and to discuss ideas around them. But ... for instance: "HahahaYou're funnyYou dislike code
generators?" Focus, focus my statements on the context that they are being applied. "My ultimate dreamtool would be where a programmer simply designs the application logic in an abstract fashion and the code to run it is generated." My ultimate dream is a
Cornucopia. I think enough has been said about code generators. If you say that I'll never have to deal with generated complex code, great its fine, but if eventually I have ... I'm not saying that this is your case. Nuno
:: I can't stress this enough, there is no need for inheritence in an :: O/R mapper, per se, simply because the E/R model isn't supporting inheritence Then you've abandoned object modeling for ER modeling. This is not a step in the right direction Frans.
Who said anything about ER modelLING, I talked about the E/R Model. That's something else. An E/R model is the 1:1 projection of a database schema in an abstract form. I never model E/R, I use NIAM or ORM. These techniques are highly abstract and result
in an E/R model. Not because they like E/R a lot, but because they have to, because what you model in NIAM can't be imported directly into an RDBMS, because these only eat E/R schema's (in DDL). So the end-result is an E/R model. That's it. Looking at that
model, you can't find any class hierarchies directly. I didn't 'abandone' Object modelling for E/R modelling (whatever that is), because it simply doesn't exist, E/R model doesn't understand objects and class hierarchies.
:: I'll look into implementing inheritence functionality just to make the purists happy You'd make a lot more people happy then purists by supporting an OO model design. We're all C# programmers here. I for one of had my share of ER modeling and am happy
to leave it in the past. Again, I never talked about E/R modelLING. I chose to use the end result of where all data ends up: the database schema, which can be constructed as an E/R model. E/R modelling is not a good technique to design a schema. This is
because you don't work with an abstract model, but with the direct result of that abstract model. In the abstract model a single change can lead to changes to more than one table/relation/whatever, which is exactly why modelling on the level of the E/R model
shouldn't be done. Nevertheless, you can't avoid it as the end result. Even when you pick a class hierarchy with added relationships and look at that as a NIAM model (you can), it will end up in an E/R model. Because of that, you have to FACE the consequences.
One of these is the fact that supertype/suptype relationships in the abstract model cannot be modelled in E/R, and thus require DATA. This is not data-independent. Imagine a class hierarchy: Employee<-Manager. You model this away in E/R probably with 1 table
with a flattened out hierarchy, because that's the most efficient. (you can also use 2 tables with a pk-fk relationship of 1:1 between the keys of both tables) When you do this, and most do it this way, you need a column 'Employeetype' too to distinguish which
rows are Employee rows and which are Manager rows. Now, your class model CHANGES: Employee<-ManagingEmployee<-Manager and Employee<-ManagingEmployee<-Executive. Happy migrating your DATA, after migrating the E/R model. You now see the problem? This isn't scalable
at all. Simply modifying a class hierarchy has huge consequences in your database, not only in the model, but also in the data itself. You now understand WHY I didn't chose this route because I wanted to protect my customers from ending up with this mess?
TRUE, if you had modelled it in two different tables, you probably would have to migrate LESS data, but still. (and remember: NIAM/ORM designers Nijssen/Halpin recommend the 1 table strategy in their books!) It's a choice I as a tool developer had to make.
It's very easy to babble on a forum that inheritence is great (it is, it's just that the relational paradigm in databases is so limited) and that all O/R mappers should have / support it and if they don't they lack something and the developers of these
tools seriously don't understand something very important. Let me tell you something, 'SoulOfReality', I'm discussion topics on forums and newsgroups since 1988 and I've seen a lot of similar discussions about various topics and when you closely look at them,
the discussions are basicly fed by the same level of ignorance: "[technique X] is great, and [tool y] should have it, if [tool y] doesn't support it, it's crap!". Time and time again I fail to see why, also now, because most of the times (especially in this
case in this thread) the choice made was WELL THOUGHT OUT. There is a solid reasoning behind it. However that is also ignored, times and times again. EXACTLY the same is present in the O/R mapper cache thread. Two people with released products on the market
(Thomas and myself) elaborate why caching can be dangerous. The arguments are simply ignored, because some people think their view of reality (pun intended ;) ) is the complete view, however there is something missing: real life experience and real life results.
I asked a number of times how a 4 layer class hierarchy should be modelled in E/R. not because E/R modelling should be done, but because it is THE SAME as saying: "how should a 4 layer class hierarchy be constructed in DDL". No-one answered. I know the reason
why, you do too I hope: it's not possible. :: Hahaha You're funny You dislike code generators? ... :: Code generators are a good thing, the best thing ever happend to developers You're beyond help Frans.
I am? :) Let me try again to convince YOU why I think that. :) Programming has nothing to do with typing code. I find typing code stupid: it's error prone and time consuming. Now, if you FAIL to realize programming has NOTHING to do with typing code, don't
read any further. However also realize at the same moment that you then also don't understand WHY code generators are great and probably never will. Ok, you read on, so you agree with the fact that programming is something else than typing texts in an editor.
Now, because programming is about algorithmic design and the datastructures necessary (in an abstract way) to make these algorithms work, the ideal situation would be when you had a way to design the algorithms and the datastructures plus the interaction between
them and generate a complete executable program out of that. Because the ideal situation doesn't exist yet, we can try to reach that ideal situation by trying to abstractly design definitions and generate code out of that. This is bad? I simply fail to see
why: you use a tool to do the typing for you. You're saying you want to do the typing yourself? You want to opt for the error-prone, time consuming route over generating code? Well, if that's your vision on progress, by all means, do so, however keep in mind
that by chosing that option of typing it in yourself, you're not going to produce better code: the algorithms you have to translate to code are already thought out, so doing the typing yourself is erm... a bit stubborn I think. :) (Similar to NIH)
I realize it would be hard to convince you why code-generators are not God's Gift to Programmers, considering you've spent so much time developing a mapper based on it. I was in a similar boat myself. A fellow architect (a man I hold in high regard) disapproved
of my mapper's code generation, and I was quite defensive about it at the time considering how much effort I had poured into that tool. But when I heard his arguments for reflection, I slowly become convinced it was a better approach. Its not that code-generation
doesn't work, its just messy for the end-user. But like I said, you won't be convinced of this until you try reflection in your mapper.
Hmm, so reflection it is huh? And how are you going to use reflection on a 100+ table system? by typing a lot of code by hand, or better: all the attributes by hand: typing, error prone and time consuming. Not my choice of spending time if I can also produce
the SAME code by clicking a button. Using attributes to customize existing code through reflection is the same as generating some code to customize existing generic code. I don't see the difference. But this debate is not new: there seems to be a tough anti-crowd
which is very much against code generators, for a long time. (some are even very stupid, using C++ templates but still very against code generators, go figure ;) ). I always think about it like this: if you want to do the typing yourself, feel free to do so.
However don't cry in the end when you are still hammering out endless lines of repetitive texts while the people who chose the generator are producing error FREE code in seconds and get more done in less time.
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 never model E/R, I use NIAM or ORM. These techniques are highly :: abstract and result in an E/R model. ORM is a great example of a conceptual modeling language that hides the details of implementing a data-model in a physical format. But you are using
the wrong term. ORM doesn't result in an E/R model, which is just another abstraction. The term you're looking for is "relational-model" or database schema/DDL. Your previous comment... :: An E/R model is the 1:1 projection of a database schema in an abstract
form ...suggests you do understand that E/R models are an abstraction for a database schema (relational-model). However its obviously not 1:1, otherwise it wouldn't be abstract. ORM doesn't transform into another abstraction. What would be the point of that?
ORM has a formal transformation into a relational-model. How long have you been programming Frans? :: E/R model doesn't understand objects and class hierarchies. Yes exactly, but the whole point of an O/R Mapper is to make that leap from object-model to relational-model.
You can cry about how hard it is, but at the end of the day that's what people set to accomplish with these mappers. :: It's very easy to babble on a forum that inheritence is great...and that :: all O/R mappers should have / support it and if they don't they
:: lack something and the developers of these tools seriously don't :: understand something very important. I've never suggested that mapper's without inheritance cannot still be useful. But inheritance makes things a lot smoother for object-programmers (a
background you obviously don't come from). So I don't want to hear you dismiss inheritance as something for "purists-only", because its commonly used by anyone whose designed an application in an OO language. :: Programming has nothing to do with typing code.
I find typing code stupid Ok, I'm sure you didn't mean this in the literal sense. I think the idea you want to get across is "wouldn't it be great if computers did our work for us and made all the decisions, code-generators being a step in this direction".
Over the years, many people have thought this (*cough*...Case-Tools) and unleashed a lot of grief on any project unlucky enough to use them. Their primary mistake is assuming too much responsibilty without putting the necessary intelligence in the generator.
When a programmer uses one of these tools and it makes the wrong decision, without giving the programmer any recourse to override that decision, you wind up having to edit the generated code. *Gasp* Which naturally leads to a maintenance nightmare. :) Unless
you can go backwards like Rational Rose's UML. That's essentially what I'm getting at. My mapper, like yours, needed to generate out class definitions since we're using it for some projects with existing large data-models in ERWin or other such abortions.
But once its in a class definition format, as a programmer I'd like to keep it there. I'd like to add a new field or relationships to my class and, volia, the RDBMS updates itself modifying the table design.
ORM is a great example of a conceptual modeling language that hides the details of implementing a data-model in a physical format. But you are using the wrong term. ORM doesn't result in an E/R model, which is just another abstraction. The term you're looking
for is "relational-model" or database schema/DDL. Your previous comment... Wordgames. Even Visio's ORM tool generates an E/R model.
:: An E/R model is the 1:1 projection of a database schema in an abstract form ...suggests you do understand that E/R models are an abstraction for a database schema (relational-model). However its obviously not 1:1, otherwise it wouldn't be abstract. ORM
doesn't transform into another abstraction. What would be the point of that? ORM has a formal transformation into a relational-model.
E/R IS not abstract. It's a 1:1 projection of a schema! An abstract model would for example define something more complex into a simpler way. E/R model defines exactly what you see in your relational schema as well, without abstractions.
How long have you been programming Frans? After I graduated from university? Then almost 10 years now. I don't see why this is of any relation to what E/R model is. If you think an E/R model is an abstraction of a relational model, you are mistaken.
You don't have to believe me, reading a question about how long I am programming professional software is a signal to me the discussion is over.
I've never suggested that mapper's without inheritance cannot still be useful. But inheritance makes things a lot smoother for object-programmers (a background you obviously don't come from). So I don't want to hear you dismiss inheritance as something for
"purists-only", because its commonly used by anyone whose designed an application in an OO language.
What do you think, that I dismiss inheritence? No, I do not. I like it a lot. I use it a lot, my generated code is even using inheritence a lot. I just don't support class hierarchy mapping on a relational model (happy now?), and I have explained that a
zillionth times already. But this discussion is going nowhere. If you doubt my knowledge in this area, that's your opinion and decision. When questions like 'how long are you programming' pop up, it's time to leave the discussion, sorry.
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#)
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 09:54 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 10:31 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 26, 2003 10:49 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 12:02 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 01:12 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 01:41 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 03:33 AM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 09:35 AM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 05:15 PM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 05:30 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)