This blog contains reflections and thoughts on my work as a software engineer

onsdag den 21. januar 2009

Subsonic - not so good enough

For a week or two I've been researching the market for ORM-tools. I know quite a few by name but never tried any of them except Linq2Sql - and with the change in strategy by Microsoft (they've decided to go with Entity Framework instead) it doesn't look like a choice for the future so I went looking for something else. And Entity Framework isn't one of them - for obvious reasons.

I have tried SubSonic on a project I've been working on for the last two evenings. I was thrilled after watching the screencast and made it work within an instant in a demo application I made while watching the video the second time.

So - I fired up a new VS solution, added a website project and another class library in which my DAL abstractions would live - like this:


And then I was soooo disappointed to learn that once I hit a method in ErrorLoggerAPI which encapsulates Subsonic controller classes I would still need to have a SubSonic section in the web.config of my ErrorLoggerWeb project! There is a workaround to this where you programmaticly initialize your connection but it requires extra work and all your SubSonic controller classes has to be modified to make this work. I wasn't exactly thrilled by this discovery - the maturity index dropped quite a lot uncovering this flaw (I call it a flaw - so sue me... I'm a bit grumpy right now)

Of course one could download the source files from the SubSonic project, make the changes and call it a day... Until a new version comes and the problem persists in the new version. Or one could contribute to the SubSonic project and solve the problem for the entire community for eternity. Or one could just get it off one's chest by writing on his blog and conclude that nothing never is as good as it seems. SubSonic looks promising and there might be a better way to solve this problem but it was a showstopper on my current project. I don't want to pollute my web.config file with configuration stuff about persistence - why should my website be concerned with issues like that? It should be handled by configuration stuff elsewhere - in business logic and persistence layers where stuff like that belongs.

Regards K.

1 kommentar:

Anonym sagde ...

Yeah why would you want your configuration stored in a configuration file?

You don't need the full SubSonic config, just enough to point it to your connection string.

The web.config is the configuration store for the context of a web application. It makes total sense to have the configuration there. Otherwise you'll have to generate builds of your DAL for testing, production, staging, etc. You wouldn't have any way to change that info based on the context.