Architecture options / ideas based on the new IoC Core Repository

RSS

Modified: 2008/05/28 16:38 by martijnb - Categorized as: Development

» Architecture options / ideas based on the new IoC Core Repository

For the moment this article is simply the idea summary of Thomas Danzl and not a defined target of the Cuyahoga team. (but hopefully this one or something similar will get one)

The main target for using the IoC MicroKernel from castle is to use it's possibilities for extending complex systems and splitt it up into handy pieces / components. So the first thing is to figure out which currently existing parts of cuyahoga can be built into exchangeable modules. E.g. the ModuleInstaller, CustomContentTypes, create the base for different module types, ... maybe exchangeable in the future.

So to use the IoC every piece of code (that we want to be handled by the kernel) must be created as a component (or in the Cuyahoga world as a module).

(if someone here knows the internals of the Typo3 CMS system maybe you some concepts here are familiar)

Edit

Current Module Handling

This is based on the current SVN version of cuyahoga and based on my current knowledge of the Cuyahoga internals.

You can find a part of the class diagram of the current ModuleBase class integration in the cuyahoga system here http://www.danzl-hosting.at/site/index.php?id=40 ModuleBase-ClassDiagramPart at the bottom of the site (by the way: how can I upload images to the wiki?!?).

Current module handling:

You must derive from a base class. (no generic interface is available at the moment)
A module is instantiated at the moment it is needed by the TypeName + AssemblyName received from a ModuleType instance asigned to the current shown section.
So a module can only be a frontend extension and nothing more.

Edit

What is necessary from the point of a module developer

The possibility to build different types of modules.
Independent form a base class so modules must only implement an interface.
Installation files (install.sql) are not directly necessary (the needed information for a basic installation of a module should be in the assembly manifest as Custom attributes ... if somebody here has ever tried the MS .NET Terrarium you will know exactly what I mean :)
CustomeProperty editor for a frontend module that will be shown in the backend instead of the default environment.
Instantiation of modules is also done by a module that is registered in the kernal as a Singelton.
... any suggestions?

Possible module types (simply some ideas):

Services (used in backend and frontend; it does not have any visible part; it's a kind of API for different operations; because of the Castle MicroKernel surch services can also be sinteltons; e.g. UserHandling, FileHandling, ModulePropertySettings, ModuleInstantiation, ModuleInstallation, ContentTypes?, ..., simply every possible part that can be droped out from the core into components)
CustomContentTypes (you can add new content types that can be handled by the default internal routines --> abstraction is needed here)
Administrative / backend modules: To easily extent / exchange backend functionality. (ModuleInstaller; the possibility of a custom property editor for modules in a created section in the backend)
Design Template Modules (not really necessary at the beginning)
Information modules (to manage static / dynamic data from external ressources; e.g. currencies, ZIP codes, ...)

Simply in short: to be able to exchange / improve every possible part outside the core with new Modules / external implementations. So also working in project groups on different parts of the Cuyahoga project would be much easier.

Edit

Minimum needed information for such a module

This must be provided by a generic interface.

Module name
The key by which it is accessible from the Castle MicroKernel (here we must have guidlines how to name such keys).
Module GUID (to clearly identify each module ... maybe this is already part of the key).
GUID's of modules the current module depends on.
Module Type (and for each type maybe a specialiced interface can be provided...)
Version

Edit

How can a deployment package of cuyahoga look like?

A package consists of:

The core
Standard delivered modules (like the module installer, file handling, user handling, ...)

Edit

PROs

Only little database access is necessary to retrieve modules if you have the MicroKernel key of it (mainly if the module is implemented as "Singelton" or "Pooled" in the Kernel) --> I think in some / many situations this can improve performance instead of decrease it.
The core is very small and the project is built mainly from modules --> very easy to extend by external developers.
Can be built compatible to previous versions.

Edit

CONs

It's a long way to reach such a target. But at the moment it is only important to build the infrastructure.