RE: [coldbox:17842] [Coldbox 3.5.3] - Wirebox Question about OO models and how they get populated.

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


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 :slight_smile: ----

  • 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 :slight_smile: ----

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.



ColdBox Platform Evangelist
Ortus Solutions, Corp

ColdBox Platform:

Thank you for your insight.

I guess I’m trying to come up with best practices and guid lines. My company is new to Coldbox and I was asked to look into the Coldbox way of doing things when it came to handling objects.

Your non-coldbox advice is really helpful. My fear is that we are going to have a coldbox framework but everything inside custom coded, which defeats the purpose of using a frame work.

I was kind of looking at the basic bean as just a object for storing data. In a normal OO environment the Factory would handle all of the population of it to keep things loosely coupled.
Having fat beans simplifies it but it does tighten the coupling.

If I think of the service objects as factories I can make it work, but whats the point then in using wire box. I can see how it makes doing singletons easier, but when it comes to more complex objects I don’t understand.

I’m going to work on some test apps. Either things will fall into place for me or it might help my questions become more specific as I try to get it to work.

Thank you for your help.

I think you’ll find many folks prefer that their model remain portable between MVC frameworks. As such, my service layer doesn’t not make use of any Coldbox-specific awesomeness. For example, I’ve created abstract classes to handle populating simple values and I manage relationships directly in my service methods. As Brad said, my model can be called directly from a CFM.

It doesn’t sound like that’s something you’re looking for. The good news is… Coldbox also provides many helpful bits that help you generate services (see VirtualEntityService) and also contains many helpful utility methods (populateModel()) that will give you functionality not found in most MVC frameworks. I suggest starting from scratch on the documentation to learn what Coldbox will do for you, rather than make assumptions of what you think it should do.

Thank You for your response.,

I’ve read through the documentation and watched as many of the videos that I could find. I have made no assumptions other than I want to use coldbox as the framework. The documentation is good at showing the technical side of the functions but doesn’t really give you the why or how.

Also depending on what page you are reading so much of it seems out of date or you just get snippets, no offense entended.

I started by creating my own object factory and models but I was asked to look into using wirebox. I think there may be a misconception on the part of my company that wirebox is this one method solution to OO. In other words that wirebox replaces the traditional object factory pattern.

It sounds like the truth is somewhere in between and wirebox works with the object factory pattern. I’m sure that as I delve more into it that I will find more uses for it. I just didn’t want to go down the path of setting up my own factories or services to find out that it was not the perferred wirebox way and then have to re-write everything. But if there is no preferred way then it doesn’t matter.

I have a feeling we will end up with something similar to what you are describing.

Wirebox is not a bean factory, per se. Wirebox is, however, an IoC / DI solution.


Hi Keo,

The “request life cycle” is most important aspect of any framework. Rest of implementation is up to developer’s understanding and choice.

For example service, dao layer could be 100% independent from framework.
Developer can also take advantage of framework tools using domain layer and speed up development work.

Here is list of documentation which will help you in understanding more about framework and tools

Step 1: ColdBox Request Life Cycles

Step 2: ColdBox Configuration CFC

Step 3: Model Integration Guide

Step 4: WireBox: The Enterprise Dependency Injection Framework