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 -~----------~----~----~----~------~----~------~--~---
