> I don’t see how wirebox could choose which type of address object to use and I’m not sure where the responsibility for populating that address object lies.
WireBox wouldn’t choose. Your code would decide what it wanted and ask Wirebox for an instance of whatever object you need.
I’ve seen the UserService objects created in samples. Would I also have an Address Service object?
You can if you want. I wouldn’t though (see personal practices below)
> Would the UserService object have to know all about the the address service?
I don’t know what you mean by “all about”, but ideally the user service would only “know” about the public methods (or API) of the address service. The userService can easily get a reference to the addressService by annotating itself so WireBox will autowire the address service in when it creates the userService.
userService.cfc
component singleton {
property name=“addressService” inject;
}
I dont’ see the difference between an userservice object and an UserFactory object.
Frankly, I don’t know that there is a difference other than the name.
I think you’re looking too much at ColdBox MVC to tell you how to do your models. The real answer is, “However you want.” I know that might not be a useful answer, but the reality is that ColdBox provides support for doing just about anything you want, but it is very un-opinionated when it comes to forcing you down one path or another. Many people are using ColdBox and everyone probably handles their models (and what they call them) a little differently. Now, you’re likely to get lots of good advice on this list about how your models behave, but know that it’s just the good advice of what’s worked for us-- not any sort of mandate from ColdBox-land.
---- Begin random non-ColdBox biased advice 
----
-
I’m not using ORM-- mostly because I started building my app at work before CF ORM came out. (I kind of wish I were though)
-
I would avoid having a service, bean, and DAO for every table in your database or you’ll wind up with an anemic domain model.
-
I typically have a DAO and bean for MOST tables (those that represent entities, which excludes pure-xref “relationship” tables)
-
I group together related beans and have them all fall under a single service. This also makes sense since my services exist to handle behaviors of my application that involve more than one bean. I also call my services to create any new instance of beans (which then in turn delegate to WireBox to create the autowire the transients), but that’s just the way I do it.
-
I handle object composition (has-a relationships) with some hand-built lazy loading. So, the user object loads and persists the address object via a service method the first time it’s requested.
-
I don’t do inheritance (is-a relationships) as much as I’d like, but that’s because we use Peter Bell’s IBO pattern which requires a collection of entities are stored as an array in a single object which makes polymorphism harder. (I kind of regret doing that now though)
-
When I do inheritance, the service makes the call as to what object it’s going to create when it’s asked to create something.
-
If it’s SQL (except QofQ) put it in the DAO.
-
If it’s a behavior of a single object, try very hard to put in the bean over the service. (fat beans, thin services)
-
If it’s a behavior of several related objects, put it in the service, but still keep the service code as thin as possible (delegate to beans where possible)
-
The most important piece of advice, is your app should live entirely in your models. ie, if you have a shopping cart-- you should be able to do everything you need to create and populate that shopping card in a test page without hitting a handler. Keep business logic out of the handlers, and just let them push form fields around and set views.
---- End random non-ColdBox biased advice ----
Feel free to ignore as much as the above as you want-- it’s just how I prefer to do things.
If you have questions about what I do, please ask.
More importantly, if you have questions about how to accomplish what you want to do, please ask.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com