Business Model + Database Mapper + Joins
I am studying business models and UML. I read that a 'Model' is a series of 'Business Objects'.
From what I have understood a model would be 'Blog' whereas the business objects could be 'Post' and 'Comment'. The 'Blog' decides which objects to use and how they are to be persisted with appropriate mappers.
I have thrown together a few UML diagrams to explore this concept and it does seem quite logical. However I am a little confused:
Issue #1 - In Joomla models appear to represent a s开发者_如何学Cingular 'Business Object' (as opposed to coordinating multiple business objects and mappers). Does Joomla adopt a different approach to models?
Issue #2 - Is it acceptable for 'Mapper' objects to perform left joins in queries? Or should this kind of logic be moved into the 'Service' layer?
It seems most logical to utilise left join capabilities of the database, but I cannot figure out how this fits into (Mapper + BusinessObject + Model + Service) design.
In a lot of frameworks and apps you will find that a Model = Business Object and that often times the Mapper is internalized into some kind of singular base model that all others extend. You'll also find that many of them lack a well defined service layer.
This feeds in to your second question about the mapper and service. I usually dont use service layer, but ideally you mapper would be fed the data from the DB which i suppose would typically reside in the service layer, then it maps that data into the business objects. However, When using a mapper i often integrate the table specific db logic directly into the mapper in the private or protected scope.
However in most cases im using an ORM that typically implements Active Record so there is no real isolation of the mapper per se in terms of how you are describing it, then tend to function in the way i described above in my first paragraph.
Also Joomla is probably not the best app to study these concepts with. Actually most PHP apps like this arent really good examples whether its Joomla, PHPBB, Drupal or otherwise :-)
In the java language the persistence annotations are written as java annotations in the code. This is really cool because you can focus on objects and therefore model you application within a class diagram.
Note that only the class diagram has a real code equivalent while other diagrams are using Model Driven Development with a code generator. This is important to see that only the class diagram could be used for Business object and mapper together.
You can still use AndroMDA and create persistence layers using code generator but I think this approach is now dead when using Java code.
How it works. You model class diagrams to create the static object (e.g. packages, classes, interface, enum etc....) of your applications in a class diagram. You then add persistence stereotypes which will create immediately java annotations in your code. Finally to create your database you only need to use Hibernate mapper which will take the java code in entry and generate a database. At deployment stage you will need to code directly in the code sql queries related to your database but this is the latest and usually none critical development which could be done in an offshore country
精彩评论