A New Year and a New Engagement
Posted by Nicholas Blumhardt | January 09, 2008 19:39
I have recently been fortunate enough to join Patrick, Mark and Gang from ThinkAbout Solutions to work for Dataract. Everyone is proving fantastic to work with, and the task at hand is adequately challenging :)
Dataract create, among other products, a workflow solution integrating WWF and SharePoint. The level of customisation provided to clients is going to be a rich source of interesting design tasks. IoC is very handy in these situations, however I'm interested in refining approaches using ORM and IoC in an integrated way to create customised domain objects with data mappings that are flexible and maintainable. Limiting the amount of generic schema is always tricky in any customisation job - it would be great to be able to eliminate it altogether.
The intersection of ORM and IoC is an area where extremely rich and powerful domain models can be built. Surprisingly, not too many people seem to have tackled this yet and there is definitely room for additions to the collection of best practices in this area.
Something I've been considering, and perhaps will write a future article on, is the requirement in most (perhaps all) data mapping frameworks that domain objects have a parameterless constructor. IoC container support would be very easy to add, in most cases, however there may be some residual issues surrounding dynamic proxies...
If you're working with a system that creates or decorates business domain objects with services using IoC, it would be great to hear about your experiences.
Incidentally, I have posted an article on the Autofac site about the use of modules when structuring systems with IoC. Feedback would be great if you get a chance to check it out.
Comments
Posted by Rinat Abdullin | January 11, 2008 22:55
Hi, Nicholas. I've just been fortunate to stumble upon your autofac container. It looks to be a really potent IoC. You might be interested to hear that it steadily compiles to work under .NET 2.0 as well - all the tests are green (there's a post on that @ rabdullin.com). PS: Yes, the module approach is a good way to logically organize components. I got used to it since the SCSF applications. For the xLim 2 type of solutions I've simply been using IFacility from Castle IoC to explicitly load all the relevant Business Object mappings/schemas, workflow micro controllers and custom UI handlers for the assembly (that's basically module functionality). That just feels more appropriate and yields more control than handwriting XML or doing batch registration.
Posted by Nicholas Blumhardt | January 12, 2008 06:59
Thanks for posting, Rinat. I had a look at the xLim documentation on your site, it sounds like a really interesting, extensible platform. It is fantastic to hear that you are able to use Autofac on .NET 2.0 - great work! - I really didn't imagine that it would be possible. How far into the future do you expect to be on that platform? I'll keep your 'compatibility layer' in mind if Autofac goes any further into the new platform features. If you continue to evaluate Autofac for xLim, please let me know what you find - there is a forum on the Autofac site if you'd like to ask any questions or explore new ideas.
Posted by Rinat Abdullin | January 12, 2008 09:49
Nicholas, Actually, compiling autofac with the .NET 2.0 was extremely trivial - I've just followed the tips on getting support for the .NET 3.5 features into .NET 2.0. I've posted in the blog link to the code for that does it for autofac, JIC. About the "keeping compatibility layer in mind" - do you use any integration server for this project? If that's interesting then it would be trivial to automate everything by just adding another build configuration. Although I do not think that it would be easy to break the inherent .NET 2.0 compatibility of autofac. I'm planning to stay compatible with the .NET 2.0 for quite some time (will try to move towards Mono .NET 2.0 compatibility), since there is quite a number of situations out there, where users do not have .NET 3.5 compatible OS'es. That just means that the core code for the desktop clients should be .NET 2.0 compatible, and then the extension modules would be able to provide platform specific UI implementations via the IoC magic. And I'll definitely continue to evaluate the autofac. Although there's already 65% probability that it would do the job better than Castle (or could be made to do one). Thanks again for such a nice IoC solution. PS: xLim is not a specific platform, it is just a set of principles/guidelines that come from some limited experience and serve specific purpose of efficiently building flexible and light distributed information management systems))
Posted by Nicholas Blumhardt | January 12, 2008 11:24
I like the idea of accumulating practices and guidelines, along with supporting libraries and tools, much more these days than the idea of building large integrated frameworks. Much easier to keep evolving incrementally as each project comes along. There isn't yet a CI server for Autofac - it would be handy though. In my last job we did something like you suggest to maintain Mono compatibility in our codebase: our CruiseControl.NET server ran the unit tests under both MS.NET and Mono. I might look at getting CC.NET going for Autofac under Linux once those couple of Mono test failures are dealt with (my servers run Ubuntu so I might as well.) MicroKernel has a lot of existing code out there - I think you already mentioned policy injection on your blog... There will definitely be things to add or tune. Still, I'd have trouble going back... Keep me posted!
Your Comment
Disclaimer: These articles represent the opinions of the authors and may not match the official position of Ubik Systems Pty. Ltd. Confirmation should be sought on all matters involving professional advice.
Posted by Nicholas Blumhardt | January 11, 2008 03:50
By the way - the whitepaper on Linq 2.0 (you'll have to google it) talks about composing systems based on ORM. You should read it if you're intersted in this kind of stuff...