A few weeks ago, I released WilsonORWrapper, a framework built around Paul Wilson’s O/R mapper. Since then, I’ve been busy rewriting it, improving existing features and adding new features to the mix.
There’s a lot of changes coming, and there are many breaking changes. Among the biggest changes include:
- Single assembly distribution. The previous
Servicesnamespaces are now combined into a single DLL.
- Integrated logging services. Logging services to log to the Windows Event Log or to text files using NLog or Log4Net is included. O/R mapper command interception is activated for all debug logging levels. Adding other logging services will be easy in the future, thanks to a pseudo-provider model.
- Integrated cache services. A caching framework is available, and a cache interface to the ASP.Net cache is included. Caching to memcached will be added in the near future. Adding other caching services will be easy in the future, thanks to a pseudo-provider model.
- Simplified configuration and initialization. Simple in that it’s not required unless you want to change default settings, and everything is done from your application’s config file. Further, all components are self-initializing — just write code, no need to call any initialization or construction methods.
- Improved services interface. Want to retrieve an object? Use the
Retrieve<T>static class. Persist an object? Use the
Persist<T>static class. Access the logger? Use the
Loggerstatic class. (A static
Cacheclass is yet to be written.)
- Extensive unit tests on the framework to ensure things work.
- Updated CodeSmith templates work just as they did before.
The current code release for this is available in the “combined” branch of the Subversion repository. There’s still more work to do before this release replaces the current trunk, but I wanted to give those few who pay attention to this project a heads-up on the forthcoming changes.
Feel free to check out the current code distribution and let me know what you think.
0 thoughts on “Major revamp of WilsonORWrapper coming”
Are you still maintaining your original “DataMapper” templates? I really like those and I’m not convinced about advantages of the new approach (packaging that couple of classes into one or two separate assemblies).
I still prefer building my own Data.Entity.dll and Data.Service.dll without any other dependency (expect WilsonORM of course).
I will probably keep up with them, though the full scope of changes implemented in the WilsonORWrapper will probably not be carried over — though I can’t rule it out altogether.
Once I update the wrapper, I will probably look back at the basic templates and merge some changes.
I understand the desire to avoid dependency, but dependency isn’t necessarily a bad thing. There’s certainly no reason to avoid dependencies just for the sake of avoiding them — unless you have a specific reason to do so (i.e. security, etc.), and if you did, I’d be interested hearing about them in order to address them in the wrapper project.
Hello there, I’m trying to compile the WilsonORwrapper but I’ m getting several errors like the one below:
The non-generic type ‘Wilson.ORMapper.OPathQuery’ cannot be used with type arguments
Do you have any idea what this may be?
It seems I was using the old WilsonOrMapper.dll with no support for Generics. It is now working as expected.
Glad you worked it out — please let me know your feedback on the wrapper!
And yes.. the Wrapper is .Net 2.0-only.
Thank you for bringing life back to the WORM templates. I’ve finally got a new project where I can pick a new framework to work with and have decided to go with yours coming from PWelter’s. I’ve been generating code in the latest WORM versions I’ve found and yours is at least well documented (in comparison) and looks to have some momentum.
My new project will have windows and asp parts. Please consider windows applications when adding new functionality (where possible – at least try not to break windows application options..). I mention this because you have discussed and are discussing again a caching addition which in the past you had just mentioned along with asp. I’d be disappointed if that functionality would break generated code working with windows applications – plus it’d be nice if the caching app worked in both environments.
Thank you for taking the initiative to get things rolling again!
Everything moving forward should work with ASP.Net and Windows Forms applications. In fact, there’s no reason why they wouldn’t work in Windows Forms applications right now (I have used them in such in the past).