Modifying the OO logic should have no impact on the DB. Modifying the internal implementation of a SP should have no impact on the OO logic. Maybe I am having a slow day, but I fail to see how changes in your data model (which the DB represents) could have 0 impact on the OO side, except if that changes is meant for another application/system using the same data.
Sébastien On Wed, Jul 23, 2008 at 4:57 PM, Peter Ritchie <[EMAIL PROTECTED]> wrote: > Yes, those are changes to the abstract entity, a two-sided change. I'm > not talking about those types of changes. I'm talking about a one-sided > change, a change that doesn't change the design of the abstract entity but > changes the implementation of that entity on one side. > > How do you manage those one-sided changes (especially on the business > logic side) if you're always generating code from DB schema? I'm saying > you're more tightly coupled if you're doing it that way; the > implementation details of the business entities aren't free to change as > needed. (by implementation details I mean implementation that doesn't > affect the design of the entities). I agree, there's always coupling of > every component in a system; that's not the coupling I was talking about-- > although I think it's obvious. > > On Wed, 23 Jul 2008 16:46:19 -0400, =?ISO-8859-1?Q?S=E9bastien_Lorion?= > <[EMAIL PROTECTED]> wrote: > >>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
