I'm not allowed to question your expertise? When you or thona or anyone says something incorrect, I'll correct them. Don't take it personally.
Heh :) Look, I really am at an age and knowledge level that I don't have to take lecturing of some sort in any forum by anyone unless I make a terrible mistake. What you tried was playing wordgames about E/R model and abstraction levels. You can't show
me an area in an E/R model where something is abstracted away from the underlying relational model so that's why I used the term E/R model. You knew that, you knew that I used 'E/R model' as a term to refer to a relational schema, the schema that is in the
database. If you then still want to try to trick me into an error and 'win' some argument, then you win. :) It's not a pissing contest, it's a theoretical discussion we're holding here. If you think you should lecture me, by all means do so, but don't be surprised
you end up discussing a topic by yourself without me as a discussion-partner. As I said before, I don't have to prove myself anymore, I have a degree in CS, I have a lot of experience in designing and writing software systems (and not small systems either)
and if you want to try wordgames with me to trick me into errors, that's perhaps your way of discussing a topic, however it's not my way of discussing a topic. If you think E/R model is some sort of abstraction of the relational model, fine. It then comes
down to a definition of 'abstraction' and I don't think that's in the scope of this forum. :) I don't know you, SoulOfReality, perhaps you know twice as much as I do. Perhaps I can learn a lot from you and you will not learn anything from me. However I get
the feeling you think YOU know it and I'm still in the 'unknown'. I think you are wrong. Please, consider that option too. No hard feelings.
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#)
Point well taken. I didn't mean to catch you in some word game, only your earlier posts didn't make sense. But I think its clear now, you've built a mapper specifically geared for relational models and I'm sure that appeals to a large audience. Its not what
I perfer, but we've already gone there. End of discussion. Oh and btw... :: I don't have to take lecturing of some sort in any forum by anyone Plz remember you are the one who started lecturing people in this thread. Don't give what you cannot take.
Hi Frans, Ok, now we are getting somewhere. I respect your knowledge and experience in principle (that is all I can do in a forum) if you respect mine Frans. "It's very easy to babble on a forum that inheritence is great" One thing that I've learned in software
developement is that any technology is good as long it is used properly. You have insinuated that I was a Purist and still have not explained me why (plus some other things). I think that this kind of insinuations in order to cloud ones observations with nothing
but icons that are commonly reconed as negative should be refrained unless you prove your point with facts. "how should a 4 layer class hierarchy be constructed in DDL" What is the problem of having four tables linked with each other, and a in each table an
attribute indicating the class representing each level? Eventually one can have a view joining the four tables. This is one approach there are more 2 at least that I know. "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." It may not be the most efficient. "Now, your class model CHANGES: Employee<-ManagingEmployee<-Manager and Employee<-ManagingEmployee<-Executive. Happy migrating your DATA, after migrating
the E/R model." I understand that this may seam to be a problem, but it is not a problem becouse it is not common practice. It may happen, but once the model is established and correct for the given problem domain, extending the systems features hardly requires
this kind of changes to the model. It may, but is not common. Furthermore, this problem is also shared with E/R. Suppose that you have a E/R Model A-C. Software is deployed. After 5 months you decide that the application needs new feature. You change the model
to A-B-C. Whouldn't you have to migrate data? The point is, every time you change existing object associations/inheritance (existing facts in ORM, relationships in E/R) you have to migrate data. "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"
Caching can be dangerous indeed, but I'm afraid is a necessary Evil for O/R Mappers. I'm prepared to change my mind on caching thought, where can I find those papers stating why it is dangerous, but not only that but also proposing a complete alternative?
I think they are a necessary Evil becouse without them database calls will much more then common ADO.NET approaches. Unless, the tools over the table function more like "DAO"/R Mappers I can't se how caching can be avoided. Nuno
Plz remember you are the one who started lecturing people in this thread. Don't give what you cannot take.
. It was not my intention to lecture, just to express a view on the matter. Perhaps that was understood as lecturing, which was not the intention of my texts. :)
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#)
Hi, For the sake of sharing ideas and not attacking ideas or opinions I'm writing this email. The more experience people are, more responsibility they have over their comments. One of the reasons why Frans wrote why Hierarchy Mappings should be kept out of
the O/RMapper was: "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. Now, your class model CHANGES: Employee<-ManagingEmployee<-Manager and Employee<-ManagingEmployee<-Executive.
Happy migrating your DATA, after migrating the E/R model." I have already counterposed this argument with this. "this problem is also shared with E/R. Suppose that you have a E/R Model A-C. Software is deployed. After 5 months you decide that the application
needs new feature. You change the model to A-B-C. Whouldn't you have to migrate data? The point is, every time you change existing object associations/inheritance (existing facts in ORM, relationships in E/R) you have to migrate data." This to say that the
phenomena is not concerned specifically with Hierarchies, but Modeling in General whatever modeling strategy you use (E/R/ERD, ORM, UML/OO). So considering that this example was put on the table as relevant by an experienced professional, I would like to know
more about it, maybe I'm missing something. But suspect there is no problem (it is an artifical problem) in reality, at least is no more then the common!!!!! Having said this, the example provided by itself is interesting enough IMHO to be analysed with more
detail. I don't know if its common to use Hinherintance to model the business facts sustaining the presented model (Business Roles), but if it is maybe my observations will be usefull for one to get a better model. The model presented by Frans is the following:
"Employee<-ManagingEmployee<-Manager and Employee<-ManagingEmployee<-Executive" The underlying intent of this model seams to be in defining Business Roles for Persons collaborating in a Business. In that sense the presented model as several flaws, that is
for this, inheritance should not be used blantly. Why? Business Roles are usually defined to establish persons responsibilities over a "contract", "action", in sum a Business Event. The roles of a Person can be many, in one case can be of Executive, another
as Manager, Programmer, Employee (employment contract), Clerk, Secretary, etc etc. So basically an Employee can have several roles within a company. The presented model suggests that the Employee only has one Role (Executive or Manager). This is a model asking
for trouble. As we know an Employe can assume several roles in a Company, and along time its roles might change (I can be an Manager at one point, and then be promoted to Executive for instance). Within this context I suggest the following: Person (Party)
- Employee (Role) Employee (Role) - Manager (Role) Employee (Role) - Executive (Role) "-" is an association. My advice is not use hinherintance to model Business Roles, but associations. My advice as nothing to do with the inadequacy of an O/R Mapper or E/R
in general for persisting OO Models (the objects not the model), but with the problem domain. A complete explanation about this is on "Streamlined Object Modelilling" and "Java Modeling in Color - Enterprise Components". Quite often hinherintace is an artifact
that is not well understood in practice. If you think inheritance is a "is a" relationship think again. Is much more than that (it can be is only a), so it can be something that is different then what you really want to express. Due to this challenge Hinheritance
all the time. If you see a model describing a business problem that is far Deeper (lot of hierachies) then Wider (less associations) is oftent the case that is a rigid model (not very flexible), this is my Precept. My experience is that if one follows good
OO Modeling practices there is little problems in mapping the OO Model to an ER Model considering that one is using an appropriate O/R Mapper. Take it easy, Nuno Lopes
One more ORM tool: DataObjects.NET http://www.x-tensive.com/Products/DataObjects.NET/ Relatively new and quite feature-rich ORM tool. It uses rintime code generation that is completely transparent for developers.
DataObjects.NET does have some interesting features (automatic transactions for one). However, one big hole is that it does not allow the mapping of tables/columns to the classes/fields. So this tool cannot be used with existing DB schemas. The handling of
inheritence is another weak point. It uses seperate tables. Support for single table inheritence would be nice. - Eric McVicker
DataObjects.NET has two features making support of single table inheritence almost unnecessary: - It builds a separate view for each persistent class that consolidates all properties of this class. The view devinition uses only inner joins on 64-bit ID column.
- It maintains FastLoadData property (read more about this in DataObjects.NET Manual) - this allows to instantiate any persistent object with all non-[LoadOnDemand] properties much faster - actually it's necessary to fetch only the corresponding row of DataObject-related
table to perform this. Nevertheless this property can be unused (e.g. if FastLoadData is empty, DataObjects.NET uses standard instantiation schema).
::DataObjects.NET has two features making support of single table inheritence almost ::unnecessary: Sadly, this is marketing hogwash hiding reality. ::- It builds a separate view for each persistent class that consolidates all properties of this ::lass. The
view devinition uses only inner joins on 64-bit ID column. Ah. What about thinking about the performance implications, please? Mapping multiple inerhitance levels into one table is normally done to AVOID having inner joins. A iew does not avoid them, but hides
them. They are still there. ::- It maintains FastLoadData property (read more about this in DataObjects.NET Manual) - ::this allows to instantiate any persistent object with all non-[LoadOnDemand] properties ::much faster - actually it's necessary to fetch
only the corresponding row of DataObject- ::elated table to perform this. Nevertheless this property can be unused (e.g. if FastLoadData :: is empty, DataObjects.NET uses standard instantiation schema). Which is anything but "special". It is absolutly common.
Actually one feature that singles out toys from good mappers. Now, dont get me wrong - they have some nice features (that I think of adding to the EntityBroker, too), but the two you mention are non-issues. Actually, sadly, on their website they really hide
their great points in a tremendous amount of marketing blabla. I really like some of their points, though - multi lingual properties are a pain manually.
SoulOfRealit...
Participant
775 Points
155 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 05:45 PM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 27, 2003 09:34 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 09:52 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 28, 2003 12:28 AM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Sep 28, 2003 08:49 AM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Sep 28, 2003 12:02 PM|LINK
x-tensive
Member
190 Points
38 Posts
Re: O/R Mapping Tools for .NET
Oct 03, 2003 05:20 AM|LINK
with built-in access control system
http://www.x-tensive.com/Products/DataObjects.NET/
JOAC
Participant
1880 Points
376 Posts
Re: O/R Mapping Tools for .NET
Oct 03, 2003 07:12 PM|LINK
x-tensive
Member
190 Points
38 Posts
Re: O/R Mapping Tools for .NET
Oct 07, 2003 05:10 AM|LINK
with built-in access control system
http://www.x-tensive.com/Products/DataObjects.NET/
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Oct 07, 2003 06:58 AM|LINK