Page Comparison

...

Aptify has started to adopt the Unity dependency injection framework into its code base. If you are unfamiliar with DI you can think of it as a 'plugins plug-ins everywhere' approach. Aptify already has plugins plug-ins in specific key locations of the framework. Entities can have plugins plug-ins for CRUD operations, record viewing, and duplicate checks. The order taking process support plugins for kit expansion, shipping and handling calculations, and pricing. But all of these features require additional development effort on our end to enable. In many formalized areas of the application (like the GE and orders), this makes sense to build out, as we envision most customers wanting to make changes there. But in other areas, this additional effort might may not be worth it yet. We may not know how often customers want to configure a particular area, or we may not be ready to finalize the metadata in the database. But not having the ability to drop in different implementations would limit our ability to respond to our customer's needs. Using DI allows us to provide many more configuration points with little overhead and increases our ability to automated testing of our code.

...

DI is mainly done with constructor injection right now. We provide full access to the Unity container so any type of wire up supported by Unity is possible.

...

• Process Components - you will find that most new process components have their dependencies injected in their constructor. Standard dependencies remain unchanged here. For example, the Process Component Config method is still how you obtain your instance of AptifyApplication. But if you look at the documentation for the component ShoppingCarts.CartProductValidationComponent, you will see its constructor takes a list of ICartProductVerifiers. This component doesn't know or care which ICartProductVerifiers it gets or how it gets them. It relies on the DI container to supply whatever implementations have been registered.
• Endpoint Security Framework - The new end point endpoint security framework allows security requirements of any type. You can use the DI Framework to add new requirement types.
• Services Exception Framework - The new services exception handling framework supports DI to allow new handlers to be registered to the system to handle exceptions.
• Output Mapping - When translating business logic output into the output entity object, by default the framework provides mappers for the generic entity, data tables, and POCOs. If you need support for an additional type , or want to take over the output mapping process yourself, this can be done through DI.

...

Some areas of the framework require you to tell us about your implementations in order for them to be picked up and used by Aptify. The security framework and exception handling framework are managed this way. If you are not configuring in these areas you do not need to use DI. But you may find it useful as a means for limiting the scope of what you're changing in your system, or to increase the test-ability testability of your code. For example, if want to write a process component that calls a 3rd party service to obtain information, it would be useful to inject the object responsible for talking to the 3rd party service in the constructor. This allows you to place the component under test with a mocked 3rd party service object, and swap the mock out for the real service in production.

...

The answer is 'it depends'. In some areas of the framework (like security and exception handling), we have a common interface and the framework asks the DI container to inject all implementations of that interface. In those scenarios, you must register your implementation type or Aptify will not know about them.

...