DI/1 is available for early testing!

August 13, 2011 · 6 Comments

After a lot of things delayed the alpha release of FW/1 2.0, I've now found time to work on DI/1 again and get it into a usable shape. The idea is that you point DI/1 at one or more folders and it searches those folders for CFCs and builds a bean factory to manage them, all by convention (so no XML required!). If a CFC is found in a beans folder, it's assumed to be a transient, otherwise it's assumed to be a singleton. If your beans all have unique names, you can use those names to reference the beans directly (either via autowiring or the getBean(name) API on the bean factory). All beans also get an alias which is the bean name followed by (the singular form of) the folder name. If you have the same CFC name in several folders, you'll need to use the alias to reference it.

Imagine this folder structure:

/model
    /beans
        customer.cfc
        invoice.cfc
        product.cfc
    /services
        cart.cfc
        sales.cfc
        product.cfc

Create an instance of DI/1:

var beanFactory = new ioc("/model");

The bean names will be: customer, invoice, productBean, cart, sales, productService (with aliases for customerBean, invoiceBean, cartService, salesService).

DI/1 supports dependency injection, by name, through constructor argument, explicit setter methods and property declarations (with implicit setters enabled).

The documentation and the examples are a bit sparse - and right now the example assumes you have FW/1 installed - but hopefully there's enough to get you started. The project has also been submitted to RIAForge now that DI/1 is in a downloadable state. DI/1 requires Adobe ColdFusion 9.0.1 or Railo 3.2.2 (or later). Feedback welcome!

View count: 25420

Tags: coldfusion · di1 · oss

6 responses so far ↓

1 Michael Long // Aug 15, 2011 at 1:38 AM

I find it a bit funny that for a long time we were supposed to do half our programming in XML, defining to a T every function, view, and object model. In effect, duplicating our code.

All because, somehow, writing a XML file that specified how two objects were joined together was "purer" than writing a controller in CF that loaded and linked two objects together.

XML, good. Code that does the same thing, bad.

Now it seems the pendulum is beginning to swing the other way. We're wising up to the fact that writing scads of XML to wire up systems is a lot of duplicate make-work that a computer could do. And do better, faster, and with fewer errors.

So now we're into auto-discovery and auto-wiring and minimizing the amount of XML, and even (with CF8 ORM) the amount of CF we need to write.

It only took, what, ten years to figure it out???
2 Steve // Aug 15, 2011 at 7:48 AM

Thanks Sean, I'll be excited to test this out. I like the convention over configuration approach.
3 indrajit chowdhury // Oct 14, 2011 at 11:25 PM

Hey Sean,

Excuse my ignorance but what exactly do you consider a service. For me a service is something akin to a db gateway however I notice you have a services folder in the model directory which seems to imply it's some sort of model in the MVC paradigm.
4 Sean Corfield // Oct 15, 2011 at 10:28 PM

@Indrajit, the "Model" in your MVC application is everything that isn't the "View" or the "Controller". The Model (singular) is comprised of all the domain objects and "services" that orchestrate operations across multiple objects. And, yes, the persistence aspect is part of your Model in a general sense. Does that help?
5 indrajit chowdhury // Oct 29, 2011 at 2:00 AM

Thanks for the update sean. Looking forward to migrating to FW/1 in our ecommerce SaaS product and possibly using DI/1 as well. Are you using DI/1 in your world singles code or is that all being migrated to clojure?
6 Sean Corfield // Oct 31, 2011 at 1:28 PM

In order to replace ColdSpring with DI/1 at World Singles, I need to figure out an idiomatic replacement for declaring factory beans/methods. Once that's in place, we'll be using it in production code.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...