WireBox : Dependency Injection & AOP
7.x
7.x
  • Introduction
    • Contributing Guide
    • Release History
      • What's New With 7.2.0
      • What's New With 7.1.0
      • What's New With 7.0.0
    • Upgrading to WireBox 7
    • About This Book
      • Author
  • Getting Started
    • Overview
    • Installing WireBox
    • Getting Jiggy Wit It!
      • Instance Creations
      • Binder Introduction
      • Scoping
      • Eager Init
      • How WireBox Resolves Dependencies
    • Migrating From ColdSpring
  • Configuration
    • Configuring WireBox
      • Binder Configuration Properties
      • Binder Environment Properties
      • ColdBox Enhanced Binder
      • Types & Scopes
      • Data Configuration Settings
      • Programmatic Configuration
    • Mapping DSL
      • Mapping Initiators
      • Mapping Destinations
      • MapDirectory() Influence & Filters
      • Persistence DSL
      • Dependencies DSL
        • Mapping Extra Attributes
      • Mapping DSL Examples
      • Influence Instances at Runtime
      • Processing Mappings
    • Component Annotations
      • Persistence Annotations
      • CacheBox Annotations
    • Parent Object Definitions
  • Usage
    • WireBox Injector
      • Injector Constructor Arguments
      • Injection Idioms
      • Common Methods
    • Injection DSL
      • ColdBox Namespace
      • CacheBox Namespace
      • EntityService Namespace
      • Executor Namespace
      • Java Namespace
      • LogBox Namespace
      • Models Namespace
      • Provider Namespace
      • WireBox Namespace
    • WireBox Delegators
    • WireBox Event Model
      • WireBox Events
      • WireBox Listeners
        • ColdBox Mode Listener
        • Standalone Mode Listener
  • Advanced Topics
    • Child Injectors
    • Lazy Properties
    • Object Persistence & Thread Safety
    • ORM Entity Injection
    • Providers
      • Custom Providers
      • toProvider() closures
      • Virtual Provider Injection DSL
      • Virtual Provider Mapping
      • Virtual Provider Lookup Methods
      • Provider onMissingMethod Proxy
      • Scope Widening Injection
    • Property Observers
    • Runtime Mixins()
    • WireBox Object Populator
      • populateFromXML
      • populateFromQuery
      • populateFromStruct
      • populateFromQueryWithPrefix
      • populateFromJSON
    • Virtual Inheritance
  • Extending WireBox
    • Custom DSL
      • The DSL Builder Interface
      • Registering a Custom DSL
    • Custom Scopes
      • The Scope Interface
      • Scoping Process
      • Registering a Custom Scope
    • WireBox Injector Interface
  • Aspect Oriented Programming
    • AOP Intro
      • Overview
        • AOP Vocabulary
      • Activate The AOP Listener
      • Create Your Aspect
        • MethodInvocation Useful Methods
        • MethodLogger Aspect
      • Aspect Registration
      • Aspect Binding
      • Auto Aspect Binding
        • ClassMatcher Annotation DSL
        • MethodMatcher Annotation DSL
      • Included Aspects
        • CFTransaction
        • HibernateTransaction
        • MethodLogger
      • Summary
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Getting Started
  2. Getting Jiggy Wit It!

Instance Creations

PreviousGetting Jiggy Wit It!NextBinder Introduction

Last updated 1 year ago

Was this helpful?

We have now coded our classes and unit tests with some cool annotations in record time, so what do we do next? Well, WireBox works on the idea of three ways to discover and create your classes:

Approach

Motivation

Pros

Cons

Implicit Mappings

To replace createObject() or new calls

Very natural as you just request an object by its instantiation path. Very fast prototyping.

Refactoring is very hard as code is plagued with instantiation paths everywhere. Not DRY.

Explicit Mappings

To replace createObject() calls with named keys

DRY, you can create multiple named mappings that point to the same blueprint of a class. Create multiple iterations of the same class. Very nice decoupling.

Not as fast to prototype as we need to define our mappings before hand in our configuration binder.

Scan Locations

CFC discovery by conventions

A partial instantiation path(s) or folder(s) are mapped so you can retrieve by shorthand names. Very quick to prototype also without using full instantiation paths. Override of implementations can be easily done by discovery.

Harder concept to digest, not as straightforward as implicit and explicit locations.

So let's do examples for each where our classes we just built are placed in a directory called model of the root directory.

Implicit Creation

injector = new wirebox.system.ioc.Injector();
espresso = injector.getInstance( "model.CoffeeShop" ).makeEspresso();

Explicit Binder Configuration

map("CoolShop").to("model.CoffeeShop");

Explicit Creation

injector = new wirebox.system.ioc.Injector();
espresso = injector.getInstance("CoolShop").makeEspresso();

Scan Locations Binder Configuration

wirebox.scanLocations = ["model"];

Set Locations Creation

injector = new wirebox.system.ioc.Injector();
espresso = injector.getInstance("CoffeeShop").makeEspresso();

So our recommendation is to always try to create configuration binders as best practice, but your requirements might dictate something else.