WireBox : Dependency Injection & AOP
6.x
6.x
  • Introduction
  • Intro
    • Release History
      • What's New With 6.8.2
      • What's New With 6.8.0
      • What's New With 6.7.0
      • What's New With 6.6.0
      • What's New With 6.5.0
      • What's New With 6.4.0
      • What's New With 6.3.0
      • What's New With 6.2.0
      • What's New With 6.1.0
      • What's New With 6.0.0
    • 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 Event Model
      • WireBox Events
      • WireBox Listeners
        • ColdBox Mode Listener
        • Standalone Mode Listener
  • Advanced Topics
    • Child Injectors
    • 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
    • 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?

Export as PDF
  1. Configuration
  2. Mapping DSL

Persistence DSL

The next step in our mapping DSL excursion is to learn about how WireBox will persist these object mappings into WireBox scopes. By default (as we have seen), all object mappings are transient objects and they belong to a scope type called NOSCOPE.

However, we need to specifically tell WireBox into what scope the declared mapped objects should be placed on in order for us to leverage caching, the singleton pattern, etc. This is accomplished by leveraging our persistence component annotations or the following methods if you prefer a non-annotation approach:

Note Please note that all WireBox configuration binders have two public properties:

this.TYPES - Enum class (coldbox.system.ioc.Types)
this.SCOPES - Enum class (coldbox.system.ioc.Scopes)

These classes have on themselves several public properties that are a cool shorthand way to link to construction types or persistence scopes

Method Signature

Description

asSingleton()

Maps an object to the WireBox internal Singleton scope

into(scope)

Maps an object to a valid WireBox internal scope or any custom registered scopes by using the registered scope name. Valid internal WireBox scopes are: NOSCOPE PROTOTYPE SINGLETON SESSION APPLICATION REQUEST SERVER CACHEBOX

inCacheBox([key='mappingName'],[timeout],[lastAccessTimeout],[provider='default'])

asEagerInit()

Maps an object to be created immediately once the Injector is created. By default all object mappings are lazy loaded in construction.

So just remember that these persistence DSL methods are not mandatory. If you are an annotations kinda developer, then you can easily add these persistence annotations to your classes.

// CFC
map("FunkyObject")
    .to("myapp.model.service.FunkyService")
    .asSingleton();
mapPath("myapp.model.service.FunkyService")
    .into(this.SCOPES.REQUEST);
// Java as NO SCOPE
map("buffer").toJava("java.lang.StringBuffer");
// RSS feed
map("googleNews")
    .toRSS("http://news.google.com/news?output=rss")
    .inCacheBox(timeout=60,lastAccessTimeout=15);
// Webservice
map("myWS")
    .toWebservice("http://myapp.com/app.cfc?wsdl")
    .into(this.SCOPES.APPLICATION);

Caution Please note that by leveraging scopes that can expire such as cachebox,request,session,applications,etc you must take into account the way they are injected into other objects. They can experience a DI side effect called scope widening injection that can link an object reference that expires into another object reference that does not expire (like singleton). This causes nasty side effects and issues, so please refer to the WireBox Providers section to find out how you can avoid this nasty pitfall by using WireBox providers.

PreviousMapDirectory() Influence & FiltersNextDependencies DSL

Was this helpful?

Maps an object to the integrated instance

CacheBox