|
My goal:
At the end of the day I want to use a factory to return an interface that has CRUD for a particular Business object. And which can be expressed in the aspx page not just codebehind.
ProductsFactoryDataAccessObject which returns IProductsDAO where the concrete implementation provides the implementations for sql server, postgresql, sqllite
When using the ObjectDataSource I noticed that it didn't encapsulate everything. To add extra parameters I had to attach to events "onselecting" which ended up staggered in pages, user controls where i used it.
In reality you need to inherit ObjectDataSource to truely encapsulate all the logic. See my comment: http://www.codeproject.com/KB/aspnet/ObjectDataSourceInDepth.aspx?msg=2477380
In investigating this topic i found a couple of references but no concrete "right way to do it" I'm sure i'm not the first to run into this problem so hopefully someone has a best practice journal on this.
I haven't dug into CSLA.net but i like the concept to bind both to winforms and webforms using the same setup.
Before i continue to struggle to design a solid solution i wanted to post it here to see if i got any new thoughts on the subject.
References Found:
http://www.manuelabadia.com/blog/PermaLink,guid,32e83915-a503-403e-97c7-e20dcf2e0b7e.aspx [3 articles total]
http://www.nikhilk.net/DataSourceControlBasics.aspx [3 articles total]
and probably the best hit is:
http://weblogs.asp.net/leftslipper/archive/2007/04/26/using-objectdatasource-to-do-the-dirty-work-for-your-custom-data-source.aspx
|