It could be a good future feature to have something little like BAM where it could create tables which you could interact with for some of the common patterns. Fair enough if its an external databse you would need to write code, but if its really internal to the process it would be nice to get rid of any coding and just have a designer to create a table that ends up in a biztalk database and then a designer to map what data you wish to retrieve. I think one of the concerns about doing this previously would always have been performance of someone creating a poor database, but with velocity that poor performance isnt so much of an issue??

I know it could be beneficial to some projects not to have to create custom databases and to have to worry about keeping them in sync with the biztalk backups.

Cheers,
Benjy

nice article and interesting discussion point. ive come across this design decision a lot myself too.

its always one of those where there isnt really a right or wrong answer but like you say its easy to end up in a mess.

I think normally I would say use adapters unless you can justify to yourself why not to, by this i mean when someone comes along and asks why you didnt use the normal expected pattern you should be able to backup the design decision with well thought out arguments and not just some lame excuse like spending an hour on trying to get it to work and not being able to.

I think when you do use a DAL I would prefer to initially wrapper this behing a WCF facade. Mainly for the abstraction benefits and being able to test and deploy this bit in isolation which can be very useful.

If you do have a DAL you call direct from an expression shape its probably a good practice to implement the facade pattern so you hide all of this DAL code from any orchestration, maybe even using a WCF style interface which you just happen to execute inline rather than with a remote call. This will make it easy to distribute later if you want to.

On the NHibernate stuff, ive actually been using Linq to NHibernate myself recently and must say its very nice. I havent been using it with BizTalk though. I can see where you might want to do this but i would still recommend the above approach to people about using a facade pattern. Im not a huge fan of having orchestrations work with some kind of domain model set of classes as I think you then start thinking about the problems with a C# mind set rather than a BizTalk one. I dont mind having a domain model underneath the facade “if required” but keep the interactions between BizTalk orchestrations and C# classes simple, easy to use and easy to test