Changes between Version 1 and Version 2 of DependencyInjection


Ignore:
Timestamp:
Mar 31, 2008, 6:45:25 AM (11 years ago)
Author:
lemon-head
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DependencyInjection

    v1 v2  
    1717 * reusable layout components: display of time and date, user avatars, and the entire page layout.
    1818 * typical functions like redirecting a page, etc, that we would like to reuse.
     19 * knowing which class is defined where
    1920
    2021Traditionally, we would provide all these shared services through global symbols, be it plain global variables, singleton classes, or a singleton registry.
     
    3637Now imagine something goes wrong with the object - then we would have to check all the different places where the object is modified.
    3738
    38 == Solution I: Shared base class ==
     39== Solutions ==
     40
     41=== Solution I: Shared base class ===
    3942
    4043Some of the services are typical for a special genre of classes, such as controller, models, views. These services can then be provided through a shared base class. For instance, we can make a RoxControllerBase, that provides methods for redirecting a page, to get the current request or the current post arguments.
     
    4649For instance, a RoxModelBase might want to use the database connection, or create one using MySQL username and password. Currently it would grab this info "out of the air", reading one of the globals stored in PVars. If we assume that such globals are evil, then how can the RoxModelBase get the necessary info?
    4750
    48 == Solution II: Injection of Parameters ==
     51=== Solution II: Injection of Parameters ===
    4952
    5053The solution is to give the RoxModelBase the desired info, by passing around a parameter. This can be a parameter in the controller, or in a setter method, like "setSQLUsername($username)", or, more generic, "inject($key, $value)".
     54
     55One example for a parameter to be injected can be the request, and post and get arrays. If we inject these guys as local variables, and unset the global counterparts, we gain some flexibility and get rid of evtl side effects and dependencies.
    5156
    5257The problem is, we will inject tons of different things. Much of this will happen in the bootstrap (index.php, RoxLauncher, RoxFrontRouter), but also later in the controllers, where information has to be passed on to the model and view. Like this
     
    6065}}}
    6166
    62 == Solution III: Centralizing the parameter injection ==
     67=== Solution III: Centralizing the parameter injection ===
    6368
    6469It is nasty, if every controller has to inject the same information to the model, view or page object. If it's really the same information, we could centralize it in the RoxControllerBase, like this
     
    124129 * eventually we create and inject many things that will not be needed.
    125130
    126 == Solution IV: Passed-around Registry ==
     131=== Solution IV: Passed-around Registry ===
    127132
    128133Instead of injecting the items one-by-one, we can make one big object and pass it at once. This is similar to the singleton registry described above, but this time it's not a global symbol.
     
    148153A problem we still have is, that we create objects that are only needed on a few pages.
    149154
    150 == Solution V: Dependency Injection Container ==
     155=== Solution V: Dependency Injection Container ===
    151156
    152157Instead of injecting all the finished objects into the controller or page, we want something that creates only those objects that are actually needed. So, instead of the registry, we define a container that can create these objects itself.
     
    172177See http://www.sitepoint.com/blogs/2008/02/04/dealing-with-dependencies/, "Writing a container".
    173178
    174 == Solution VI: Container and Factory ==
     179=== Solution VI: Container and Factory ===
    175180
    176181This time the container does not create the services itself, but uses a factory object for that task.
    177182
    178183
     184== Action Plan for BW-Rox ==
     185
     186Since we don't want to break existing code, everything we do should be backwards compatible. We can begin by providing redundant non-global shared services, while keeping the old global ones.
     187
     188This way, it is up to the application programmers, if they want to adopt a scheme with fewer global symbols. It will take a long time until we don't need the global ones any more.
    179189
    180190