.net barcode Creating a Micro-Kernel Specific Resolver in VB.NET

Paint Denso QR Bar Code in VB.NET Creating a Micro-Kernel Specific Resolver

The resolver used in the Micro-Kernel pattern is the Client-Dispatcher-Server pattern. The client, though, is the adapter, and the dispatcher is the micro-kernel. Therefore, the implementation is relatively simple, as the following illustrates: public class Resolver : Devspace.Commons.Loader.Dispatcher<Devspace.Commons.Loader.Identifier> { Devspace.Commons.Loader.ResolverStaticAssemblies _resolverImpl; public override void Initialize() { _resolverImpl = new Devspace.Commons.Loader.ResolverStaticAssemblies( InternalServers.GeneralIdentifiers.ApplicationName ); InternalServers.PathsResolver.AppendPaths( this ); } public override void Destroy() { } internal void AppendPaths( string paths ) { _resolverImpl.AppendPath( paths ); _resolverImpl = null; } public Resolver() { }

public Definitions.IClient CreateClient() { return CreateInstance<Definitions.IClient>( new Devspace.Commons.Loader.Identifier( InternalServers.PathsResolver.ExternalServer, InternalServers.AssemblyIdentifierResolver.Client ) ); } public Definitions.IAccount CreateAccount() { return CreateInstance<Definitions.IAccount>( new Devspace.Commons.Loader.Identifier( InternalServers.PathsResolver.ExternalServer, InternalServers.AssemblyIdentifierResolver.Account ) ); } } The type Resolver subclasses the type Devspace.Commons.Loader.Dispatcher. At the end of the Client-Dispatcher-Server pattern discussion presented earlier, I mentioned how it was acceptable for any subclass of Dispatcher to not use factories, or interfaces, and so on. The Resolver type illustrates how specific a Dispatcher subclass can become. Consider the methods CreateClient and CreateAccount. Each creates an interface instance, but the controlling parameters of which assembly to call and the context is very specific. It s specific to the implementation of the micro-kernel, and there is no way that the Client-Dispatcher-Server pattern could ever figure it out the permutations are simply too large. In this example, the Resolver type is hard-coded with respect to the Dispatcher subclass, but is generic with respect to the Micro-Kernel pattern. This is because the assembly identifiers and type identifiers are managed by a set of classes in the InternalServers namespace. InternalServers references multiple types that know which paths to use and which identifiers to retrieve. The InternalServers namespace is identical to the internal servers of the Micro-Kernel pattern, and are responsible for figuring out where the configuration information is. The micro-kernel only references those configuration entries using properties or methods.

The external servers only need to implement the interfaces defined in the micro-kernel, IAccount and IClient, as in the following example: internal class LocalAccountRemotable : Definitions.Account, Definitions.IAccount { public override void Add( Definitions.Entry entry ) { base.Add( entry ); } public override Decimal Balance { get { return base.Balance; } } }

internal class LocalClientRemotable : Definitions.Client, Definitions.IClient { public override void Add( Definitions.IAccount account ) { base.Add( account ); } public override void Remove( Definitions.IAccount account ) { base.Remove( account ); } } The types LocalAccountRemotable and LocalClientRemotable subclass their respective interfaces, but they also subclass the abstract base classes Account and Client. The subclassing of the abstract base classes, which is optional, is meant to simplify implementation of the interfaces. If you wanted to use your own abstract base classes instead, it would be entirely acceptable. However, you must remember to derive your external servers from MarshalByRefObject; otherwise, an error will result when calling the type across AppDomains. Notice in the interface method implementations of the types LocalAccountRemotable and LocalClientRemotable how the subclassed methods are called using the base reference. And one last item to note is the inclusion of the internal scope identifier, which prohibits using direct references for the types.

The last piece of the micro-kernel that needs to be implemented is the adapter. None of the pieces illustrated thus far have a has-a relationship, more an indirect uses-a relationship. The exceptions to this statement in the architecture are the micro-kernel and internal server pieces. The adapter ties everything together and presents an API that the client can use. For the banking application, the adapter source code would be as follows: public class Bank { Definitions.IAccount _account; public static Definitions.IClient CreateClient() { Implementations.Resolver resolver = new Implementations.Resolver(); return resolver.CreateClient(); } public static Definitions.IAccount CreateAccount( Definitions.IClient client ) { Implementations.Resolver resolver = new Implementations.Resolver(); Definitions.IAccount account = resolver.CreateAccount(); client.Add( account ); return account; } public static Bank CreateBank() { return new Bank(); } private Bank() { }