Thank you so much for your very complete answer!! I will read the book that Marcus recommended.
Regards. El vie, 27-03-2009 a las 22:46 +0000, Henrik Feldt escribió: > Hi Daniel, > > When you're doing a new project, it's quite easy to map the domain objects > directly to the database. The domain entities, however, contain on top of > their data, also logic and methods which make them interact with each other. > On less than Greenfield projects, it might take some creative mapping to get > as clean domain layer as possible (like event listeners, custom types and > one-to-one mappings). > > There aren't only entities (see the book Markus referred to), in the > business layer, but also value objects (e.g. the money pattern) and domain > layer services (which interact across 2..* entities) or even what can be > more thought of application services which further can performs things like > workflow invocations, invocations to other systems etc along with > infrastructure-calls, such as making sure logging works, or providing a nice > façade in front of the domain objects for consumption from a soa-service > (aka something ~WS) or a WS or simply the GUI of your application. > > In a sense the MVC pattern is very good for modeling applications without > much interconnect; in the 'classic' version, the model in some sense > interacts with the views by pushing events/allowing subscribers. Personally > I prefer something along the castle lines with more dumb (passive) views, > taking instructions from the controllers. > > Depending on what stage you're at in the application dev you can either put > a lot of what I above described as domain/application services in the > controllers; this is probably the quickest, but as you start expanding the > application with more interconnection features (consumption over LAN, WAN, > Flash), you might benefit from moving lots of what you previously had in the > controllers to application services, making the controllers rather into > something which listens to events from the business layer/tells the > application what views to show and simply validating and parsing the input > so that your application is safe from malicious input. > > The application services and domain services are close in definition and > seem to fit what you're calling the "Sales" object (depending on what you > had in mind). By naming convention ISomethingService, we know approximately > what the service responsibilities are (and are not), while a simple naming > of "Sales" might cause some confusion... :P > > Finally, the * services can often be incorporated into your domain layer > with creative use of aspects and concerns. Qi4j (Qi4j.org) uses this > technique and I've seen presentation where it's recommended as well. I > haven't seen that many examples (very few in fact) which use this, and > making sure it all works with your ORM of choice (say NH), can be tricky if > that, too, uses method interception via some dynamic proxy; perhaps Ayende > or Hammett can give you (and me) some further advice on how they would do > such as thing :p (hint hint). > > Markus talked about having different objects in data, business and gui > respectively: this may or may not be the way to go. In DDD Eric discusses > how the business layer over time becomes more of an abstract layer where > consuming upper layers provide the concrete implementations. Also DTOs (the > objects in the GUI): data transfer objects are common when you have complex > business entities; again, depending on your application, you may have custom > DTOs which selectively show parts of your business objects to services > (which e.g. other companies consume) -- this improves the problem of > possibly leaving a field as [NonSerializable] when you expand, but also > allows you to map something simpler as the output of the service (if you > expose it like that). Normally though, it's quicker and much easier to > simply use the business entities in the GUI-layer. I haven't seen many > "data" objects though, but maybe he means the "abstraction" of the DB such > as TableRow which might be hidden in e.g. NHibernate or some other ORM. > > Cheers > Henke > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Daniel Soto > Sent: den 27 mars 2009 18:53 > To: [email protected] > Subject: business objects in Monorail > > > Hello. > > Sorry for the newbie question. > > According to MVC pattern, the model are all business objects in a MVC > application. In many examples that I see, the model matches exactly with the > database model (1:1 relation). > > Can have other business objects in the model, without break the MVC pattern? > > For example: A database model have two tables, Product and Customers, and > they generates two classes with same name in the model, but it's possible > that in the model have a third class named Sales, which do some special > process over Product and Customers classes, but not necessarily matches with > some table named "Sales" in the database. > > It's possible this? > > Thanks! > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
