What is the recommended (typical) approach being used by most Csla implentors regarding the implementation of Data Access code (DataPortal_xyz methods)? Is the better approach to embed the ADO.Net code directly in the BO or abstract it to it's own DAL? Does the abstraction help or hurt code generation tactics? Are people using the Ent Lib (or DAAB) as the DAL tier and calling those methods directly from the BO's data access region? Will using the Ent Lib even work with Csla?
Questions, questions....thanks for any thoughts on these.
Many developers use things like the DAAB in their DataPortal regions.
My DAL looks a lot like the MS DAAB and it reduces the amount of code in the DP quite a bit.
It increases the readability too.
My Codesmith templates were tweaked to use my DAL instead of directly spitting out the ADO.Net code.
Joe
Thanks Joe...pardon some of my newbie questions as I'm brand new to CSLA and I'm only on page 400 , haven't done an implementation yet ![Smile [:)]](/emoticons/emotion-1.gif)
After I asked the question I realized that the Data Access region (i.e. DataPortal_xyz methods) is server side code and can therefore easily use Ent Lib or DAAB. And seeing as the Ent Lib encapsulates all the necessary ADO.NET code and can return the required readers to the DataPortal methods, that most certainly will keep the BO code to a minimum and increase readibility. And lastly I would have to think that this helps with code generation a great deal by reducing the requirements to spit out repetitive data access code.
I'm not even to the point of considering utilizing codegen utilities with CSLA until I come up to speed on using the framework manually, but I do want to know what's around the corner. I already own CodeSmith so it's nice to hear that many folks are using it successfully with the framework...although it looks like there are healthy debates going on between the ORM/UML camps and what the best tools to use for codegen might be. Thanks again.
Copyright (c) Marimer LLC