i've seen 2 methods: method 1 forces shell reference modules @ compile time (which seems contrary purpose of modular nature of prism library). in method, bootstrapper configures container using types known @ compile time.
in second method, bootstrapper configures container provide instance of container class (iunitycontainer or have you). allows shell project know nothing modules loaded, forces modules depend on given di framework (since prism doesn't seem have generalized mechanism configuring container).
which method better, or missing crucial piece of information?
the way of types registration in container depends on container type itself. prism comes out full support of 2 containers: mef , unity.
you can read types registration in development guide:
registering types unity container
during initialization, type can register other types, such views , services. this, type need have container injected module constructor. registration can performed outside code through configuration.
registering types mef
mef uses attribute-based system registering types container. result, adding type registration container simple: requires addition of [export] attribute type.
so using unity have 2 options: container reference injection , configuration. mef, can use attributes , container injection.
if want use container implementation, such autofac, have provide adapter prism.
developing prism based application, have choose 1 di container type. there nothing wrong in coupling modules 1 di framework. of course, support many of them using e.g. iservicelocator interface. development guide states:
iservicelocatornot meant general-purpose container. containers have different semantics of usage, drives decision why container chosen.in following situations, may appropriate use
iservicelocator:
- you independent software vendor (isv) designing third-party service needs support multiple containers.
- you designing service used in organization use multiple containers.
Comments
Post a Comment