Ah, you are definitely a good choice for discussing the subject :) Ok. I agree with you to a degree that I will not use inline responses, but I'll rather try to make my questions more specific.
Many of the advantages I'm trying to preserve by modelling using design patterns and common OO concepts, are about "coding". More maintainable code and more efficient changes to code (in terms of man hours) is my primary point which is in favor of OO approach. This does not mean that you can't use DB concepts instead of using OO concepts in modelling a domain. After spending about 8 years writing code around and inside some very DB oriented apps, you learn to respect the outcomes of this approach. I'm just saying that, by using DB concepts (types, relations) as the primary modeling approach, and generating OO code from this model, we loose some of the benefits of OO design. However, it is my opinion that this loss is not about the actual capability of the software, it is mostly about the efficiency of making changes to code, and up to a threshold value (very hard to determine), this is acceptable. My request for comments is about the following scenario. By adopting OO based design for domain, you can choose to completely ignore the requirement for persistence, accept it as a service actually, and use all the things like inheritence, interface based design, particular patterns etc.. After you've done this, you have a set of classes, and you actually have two choices. 1) you can now forget about all these classes, and design a db schema based model for the domain, as if you are doing the DB oriented modelling. After this you generate OO reflections of your DB model by reverse enginering this schema, and now you have two sets of "domain classes". One set is build on OO concepts, and the other one is mappings to OO concepts from DB concepts. A tool oriented summary is like this: [Classes generated from UML] <------->[connector layer/service/class]<------------> [classes generated from DB schema]<----------->[ORM services]<--------->[DB] Here, there is a possibility of overlapping, like very similar classes in both UML generated set and ORM generated set. But when inheritence and other OO concepts are used heavily in OO based set, the distinction is usually clear. Here, ORM based classes become kinda DTOs for DAOs, where DAO pattern is encapsulated in connector layer. Do you think the architecture above is overkill? Do you think that instead of modelling DB by looking at the domain, we can model it as using the class designs as inputs? I am trying to see if I can justify the appoarch above, I guess the only way to do that is to give it a try in a moderate sized project, which I have at hand at the moment, but still your opinions would be quite valuable. All the best Seref On Tue, Jul 22, 2008 at 3:48 PM, Frans Bouma <[EMAIL PROTECTED]> wrote: > Hi Seref, > > > I've just started a small web app, and I am using an ORM product for DB > > access, which is what I have been doing for the last 5 years. In the > > beginning I had my own solution, but after leaving the company I wrote it > > for, I did not take the code with me, and great products emerged for > .NET > > like llblgen. > > :) > > > The thing is, for a small project, it is almost inevitable for a > developer > > to quickly create a db schema, generate sql statements from the db design > > tool, and create the db, which if followed by reverse engineering the db > > with orm tools, and bind it to UI. It is the kind of thing that I've done > > maybe a hundred times or more. > > Not only in small projects. Often a team contains one or more DB > architects who are in charge of designing and maintaining the db schemas. > > > The thing is, when I start with use cases, and a domain model that does > not > > include any concerns for persistence, the results are different. The uml > > diagram I'm looking at uses inheritence, design patterns etc, and if you > do > > not think about persistence, the look of the code that uses this model > is > > quite clean. It is more maintainable too. > > true, from a code perspective. > > Though, one thing has to be realized: if you design a class > hierarchy > like Person <- Customer, Person <- Employee etc., these types didn't fall > out > of the sky: they're physical definitions of abstract entity types, > projected > onto program code. > > This means that it doesn't matter if you write a person and customer > class or that you create a person and customer table: both are projections > of > the same (!) abstract entity. The thing is: an abstract entity is a > definition > of something which is recognized in reality. How you create your code to > deal > with this definition is up to you, however it's wrong to ignore the fact > that > the entity is simply something that is recognized in reality, so modelling > an > entity model is really just modelling what's already there: reality > contains > these entities already. > > If a class diagram is created which contains different types than > the > ones recognized in reality, it simply means a conversion has to take place. > Too many times developers assume that this conversion takes place in an O/R > mapper layer, but that's a mistake: the conversion has to take place inside > the code: the conversions I'm talking about are actually projections: from > one > domain to the other. If the conversion doesn't take place, you can't talk > about 'customer' in the context of the program and if the conversion isn't > recognized as something required, one also can't talk about 'customer' in > the > context of reality. And especially that second part is where things go > horribly wrong in a lot of application which consume databases. > > > Now this is a clash between two different approaches, where domain info > is > > modelled first in db or in a domain model. The question is, what is the > best > > way to merge these approaches? I am really happy about using benefits of > OO > > in the domain model, but at the end I find myself writing a "manager" > layer > > which connects domain classes to orm generated classes. > > As long as your application logic deals with entity types which are > simply a physical representation of the abstract definition, you can make > decisions based on these entities with rules as recognized in reality, e.g. > based on interviews with the client, research of the organization the > application is for etc. > > The advantage of having entity types which represent elements > recognized in reality is that your code mimics that of what should be done > in > reality / is done in reality as well. I.o.w. you can reason about what the > logic should be done by simply looking at reality and how processes work, > should work, how information streams run, what information is available > etc. > > Nowadays this is called 'domain oriented', in earlier days there > were > different terms, but they all come done to the simple fact that one should > recognize what reality contains about the subject at hand and use that > information as the base of the software to build. > > Never ever fall into the trap that the class model is the > representation of a) reality and b) what should be done to make the > software > behave in reality as required. > > > I am not sure if ORM should be responsible for more than eliminating the > gap > > between relational paradigm and OO paradigm, and you see all these > resources > > referring to ORM classes as domain classes. Check out any OO design > resource > > or course, and you'll see that the modelling of a domain is rarely > performed > > in DB world, where schemas and allowed db types are your building tools. > > Eclipse Modelling Framework seems to have a binding to Hibernate for > > example, which is a clear indication of seperating domain model from ORM > > classes, and I think I am in favor of this approach, for it allows me to > do > > the design based on OO approach, and it also gives the benefit of being > able > > to isolate myself from sql. > > Though, it's nothing more than dealing with the overhead of > text-based > code which is a projection of the functionality required: if the paradigm > of > the code changes, if the language changes (e.g. from C# to haskell), the > real > program, the solutions to the problems recognized, the functionality > required, > the entities recognized in reality which are the ones to deal with aren't > changing one bit. > > Thinking in C# statements too often makes people think that what > they're typing in is the solution, is the functionality, are the > datastructures required, but they're projections of the solution, > functionality and datastructures required. Because they're projections, > your > main focus first should be on the source of these projections, which is > what > we're today call the domain model, entity models etc. > > And these have little to do with code, class models and the like. > > > On the other hand, ORM based approach simply works! I think I'm more > > inclined to accept ORM (generated) classes as domain classes when I'm > under > > time pressure and the app is small, and writing down the connecting layer > > between domain and orm layers when I have more time and the project is > > larger. > > I'd love to hear what you think about this. How do you draw the line? > Which > > approach is common in your shop? > > I wrote a couple of articles about this subject, one is in Jimmy's > book: 'The datamodel is the domain model' (I always love the reactions of > code-junkies when they see the title ;)) available here: > > http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Mode > l-is-the-Domain-Model.aspx<http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx> > and I rehashed it abit in different wording here: > > http://weblogs.asp.net/fbouma/archive/2008/05/19/why-use-the-entity-framework- > yeah-why-exactly.aspx<http://weblogs.asp.net/fbouma/archive/2008/05/19/why-use-the-entity-framework-yeah-why-exactly.aspx> > > In v3 of LLBLGen Pro we'll do both approaches, model first (dbschema > follows entity model) and dbschema first (entity model reverse engineered > from > dbschema), which both come down to simply build an entity model + mappings > + > dbschema model, and it doesn't really matter which side you started, you'll > end up in that state anyway. Nice thing is that you can directly > communicate > with domain experts _and_ database schema experts at that level, as it's > the > abstraction level already defined a long time ago in for example NIAM/ORM > (object role modelling ;)), Yourdon and later on in a set of different > names > by Evans. > > FB > > ------------------------------------------------------------------------ > 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#) > ------------------------------------------------------------------------ > > =================================== > This list is hosted by DevelopMentor(R) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
