/// Sunday, October 30
CodeInjection next steps
I'm close to releasing the CodeInjection library. The only issue I have left is how to force the debugger to step into the intermediate files InjectCode generates. I'll chat with the Boo masters on IRC and get some ideas.
So, what's next? I'll write yet another article on how to use this new facility to fill in your classes from an iBATIS.NET data mapping.
iBATIS.NET is a data access framework. If I had to categorize it, it's somewhere between Microsoft's Enterprise DAAB and NHibernate. Most enterprise projects I've been involved with forbid me or any developer from touching the database. (They eventually let me since I'm pretty good with T-SQL). In general, DBAs are responsible for creating stored procs and permissions. No direct SQL to the database. iBATIS is perfect for this since it can map any SQL including stored procedures to objects. It doesn't try to do what NHibernate does but it does map to objects which the DAAB doesn't. With code injection your code will always be in sync with your data mapping file. Of course, you could take it a step further and generate your data mapping file using AspTemplateCodeBuilder.
FYI: The ANTLR packaged with Boo generates Boo code. NICE! I found a couple of bugs and entered them into JIRA but they're minor. I used it to parse the ASP-like template files.
Although the way I suggested to implement it isn't best.
It would be better to create a hashtable that stores the symbolDocWriters.
Boo assumes one file per module.