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® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
