Help Understanding - ColdBox MVC Model Integration

Communities ColdBox HMVC
1

First off, I have been developing applications with Model Glue and Mach-II for years now, but this is my first real investigation into ColdBox. I have been going through the documents on the wiki and everything was going well until I hit the page on model integration. From my initial read here, it looks like ColdBox is trying to handle the dependency injection as well as potentially some ORM style work via Transfer? Is this correct, or have I miss-interpreted? If this is correct, then what is the reasoning behind integrating ColdBox into the application model like this? Why would I want an MVC framework which is primarily designed to serve HTML applications so tightly imbedded into my model? If I wanted to put a Flex/Cairngorm MVC framework on top of that model, it would have unnecessary properties and attributes defined on the model objects and potentially not work at all.

I am just trying to see if I am missing something here or if there is some compelling reason for having ColdBox extend farther down in the application than the controller layer.

Thanks

– Jeff

2

You don't HAVE to use model integration.
I prefer to use Transfer and Lightwire/ColdSpring

About Flex, Cairngorm and ColdBox. It's a VERY good combo.
Flex can talk with ColdBox using the ColdBoxProxy.
So ColdBox handles ALL cf-stuff.

e.g.
- Flex calls ColdBoxProxy through remote
- ColdBoxProxy calls an event
- The event talks with e.g. a service through IOC and returns data
- ColdBoxProxy returns data to Flex

Ernst

3

Jeff,

Excellent question. I’ll not speak for Luis, but he has said in the past that the model integration is to assist those who are not particularly familiar with IoC/DI ease into the world of IoC/DI. Some people like having this ability in ColdBox. Others, like myself (and presumably you, based upon your comments), do not like it and do not want our model tied in any way, shape, or form to the MVC framework.

I absolutely love ColdBox, but there is no way on earth I would ever recommend tieing your model to the framework. While there are certain benefits to doing so (such as the ColdBox Cache), I personally believe that the negative points (many of which you’ve already mentioned) far outweigh them. My model is 100% separate from the MVC framework, and can instantaneously be moved to any framework (or no framework at all) that I choose to move it to. That said, I have no reason whatsoever to move away from ColdBox. I can’t fathom moving away from it. This is just a simple case of “just because you can do something does not mean you should.”

HTH

4

I started with the "wholly separate model" view and have migrated to
more of a "loosely coupled" view. For instance, I use the DI part of
the Coldbox model integration because it is quick and easy, I don't
need everything that Coldspring does and I like the way it uses
property annotations. It feels very clean and simple.

Does it tie my model to the MVC framework? Yes and no. Yes, in the
sense that when I'm injecting my DAO into my Service and my DSN into
my DAO, I am relying upon a feature of Coldbox. No, in the sense that
what I'm really doing is relying on DI and I just happened to choose a
DI framework that comes built in to my MVC framework. If I was using
Coldspring, I'd still be relying up on a DI framework and I'd have my
models "tied" to Coldspring. Swapping from CB to Coldspring for the DI
portion wouldn't be difficult at all and there isn't anything unique
that I'm doing with CB that I would have to dramatically change with
Coldspring. So am I really tying my model to my MVC framework? I'd
argue, no really.

You can write great apps without using DI/IoC, without an ORM, heck,
without MVC or even Coldfusion for that matter. We adopt these
frameworks to make our lives easier. Yes, every one of them we adopt
brings a code dependency with it. In many cases, however, the
dependency is well worth it and some of the best ones (like Coldbox)
leave a pretty light footprint on your apps and allow you to easily
rework the way you do things.

As for the original poster's question, Coldbox has a built in IoC
container for managing DI. You can easily swap it out within the
framework for Lightwire or Coldspring. Coldbox does not have a built
in ORM and does not ship with Transfer. If you want to use Transfer,
you have to download it separately and install it. Coldbox's model
integration documentation just shows you how you can hook Transfer up
to use as part of your model and then do things like inject the
Transfer Factory into your Service layer.

Hope that helps,
Judah

5

Thanks all. These days, my application models tend to contain very
few actual cfcs and the ones that are there are very generic and are
extended by DSLs and meta-data, thus my ColdSpring configuration is
usually fairly limited as well. So, the whole concept of adding
properties etc. to the cfc definitions to allow ColdBox to manage the
model does not fit with this approach. However, I like the convention
approach to the controllers in ColdBox because I can use the same
generic controller / DSL approach to customize the controller layer as
well as the application model, so it is good to hear that the extra
hooks in ColdBox are just that. I just finished going through the
ColdSpring page on the wiki and it has some interesting possibilities.

Thanks again for the help.
-- Jeff

6

Few more observations for you Jeff. But overall, great questions and great feedback!!

ColdBox is not an MVC framework only. It is much more than that and you can choose what you need depending on your approaches, consider it as a set of libraries much like Spring. The transfer orm extras, are that, extras. There a set of libraries that will help you work with transfer. We will also release a set of reactor extras in 3.0 and possibly some hibernate extras for those working with coldfusion/java/groovy integrations. We already have a Groovy Loader project that can be attached to any application.http://blog.coldboxframework.com/post.cfm/groovyloader-2-0-released

Why would I want an MVC framework which is primarily designed to serve HTML applications so tightly imbedded into my model?

The model integration is going to be a standalone library by 3.0 and will be able to be used on any MVC implementation, or non-mvc implementation. It will follow the same suit of IoC frameworks and include conventions, injections by annotations, wiring in of webservices,java,groovy classes, time persisted objects, etc. So at the end, you will not be tied to the MVC implementation. Actually, you are not even tied to it now. The misconseption is that ColdBox is an MVC framework, when it is not. We follow the same pattern of services as Spring offers, same library, same branding, but with tons of services and libraries in use for enterprise development. Again, not all of it is used, loaded,etc. It is a development platform, where you can choose which services you would like to use.

The ColdBox MVC features are one thing, the ColdBox IOC engine is another. ColdBox was not designed as an MVC framework, but a development platform with switchable pieces. Why? Well, because the degree in which ioc frameworks in coldfusion are developed is too slow. Not only that, no documentation, no roadmap, codebase passed on from author to author and tons of overhead for a library that should have simplicity in its domain. That is why we started model integration and will be released as a separate library for IoC in 3.0, fully documented, documented roadmap and features, fully supported, training services and professional services.

If I wanted to put a Flex/Cairngorm MVC framework on top of that model, it would have unnecessary properties and attributes defined on the model objects and potentially not work at all.

Annotation based injection is NOT mandatory. Model integration supports setter injection, constructor injection and cfproperty (annotation) injection. Not only that, we have several applications at work that use cfproperty annotation apart from normal cfproperties for flex integration with no problems. We also have applications where I use model integration and I can easily switch them to coldspring/lightwire by just definining it in my coldbox.xml. Unless you start using the advanced DSL annotations (cache wiring, coldbox services, datasources, etc), your model will never now it is coldbox model integration. These are misconseptions.

Finally, 3.0 will also have other services offered as standalone frameworks:

  • MVC
  • Enterprise Cache (with multiple backend extension points: ehCache, ColdBox Cache, oracle coherence, etc)
  • MockBox (Our mocking and stubbing framework)
  • LogBox (Our logging capabilities framework)
  • AutoBox (Model integration → Dependency Injection, IoC and AOP, yes AOP)
  • Much more announced later.

I hope this offers a better insight into what COldBox is and what it is becoming. We are addressing the most challenging or setup pieces of ColdFusion development. All in sight of simplicity, extensibility and quality. HOpe you enjoy and have more questions!!

Cheers :slight_smile:

Luis

7

Luis, thanks for the most excellent (and detailed) response. I think that is invaluable information for those using ColdBox. Sometimes it’s really difficult to grasp all of the why’s and why not’s when you’re not the author, and in the end we can’t see the forest through the trees. It’s really nice to hear those why’s and why not’s straight from the horse’s mouth to help us regain our 20/20 vision.

8

Luis,

Great explanation... BTW, when can we get our hands on 3.0?

Gary Herman
831.454.0850 x.13 (Office)

Of Luis Majano

9

3.0 is in pre-alpha on SVN or by using the nightly build. It already has about 40 tickets closed and almost getting ready for a public alpha. However, you can use the nightly build as of now.

10

Luis,

Very nice explanation and thank you. I had actually just be
discussing with another developer some issues I had with the other
'monolithic' frameworks and the potential about building a new,
lightweight, modular framework where you could pick just the parts you
wanted. It is looking more like you beat me to it with ColdBox. I
have some more reading to do, but I am impressed thus far and I look
forward to getting more involved in the framework / toolkit itself.

Thanks
-- Jeff