Whether you use Repository or Active Record, when a new *mandatory* field is added to a table, that change usually ripples through the whole project, from DAL to GUI. Removing a field or changing its type would have the same impact.
>From my own experience, the only change with an effect that can be limited, to the DAL or even only the DB, is adding a non mandatory field or one where a default value makes sense. So talking about tight/loose coupling in the context of ORM has some inherent inescapable limitations. Sébastien On Wed, Jul 23, 2008 at 12:04 PM, Peter Ritchie <[EMAIL PROTECTED]> wrote: > What it sounds like to me is that you want to utilize agile software > development techniques. One tenet of this is to keep coupling very low. > This follows the basic OO principle or single responsibility (SRP). Said > in another way: a class should have only one reason to change. If you're > modeling a domain object and the implementation of the class must change > when the DB changes, you're violating SRP and have tight-coupling. Can > software that works be written this way? Of course (so, yes, this isn't > really about capability, its about responsiveness to change). But, it > means changes to one aspect of the system ripple through the rest of the > system. This makes it difficult, costly, and time-consuming to make > changes. > > The drawback of generating types from DB schema is your are effectively > coupling modeled types to the DB. Do all changes to DB schema ripple > throughout the system? Of course not; but when they do you can't make > changes in a timely fashion. Using OO principles and implementing the > Repository pattern means most changes to the DB ripple only into the > Repository implementations. > > I honestly don't think you can be agile in the long run with round- > tripping code from DB schema. It's one thing to start with DB schema, > generate domain classes from them then they live on their own. But, > coupling all the domain types in your business layer directly to DB schema > (by way of generating code from schema) means, at least some, changes to > the DB have to much of an effect on too much of the system to make it > easily maintainable. > > Do some projects work this way? It depends on what you call "works". I > find in situations like that there's lots of push-back from the devs when > the customer wants changes. The devs know the changes will ripple through > the entire system, be difficult to do, time-consuming, affect quality, > etc. If they do make the change, quality usually suffers and the customer > isn't happy. If they don't make the change then the customer doesn't have > what they want, and they're not happy. So, not being agile can affect > capability. > > On Wed, 23 Jul 2008 14:02:13 +0300, Seref Arikan > <[EMAIL PROTECTED]> wrote: > >>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. > > =================================== > This list is hosted by DevelopMentor(R) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > -- Sébastien www.sebastienlorion.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
