Apr 29, 2005 07:02 AM|xpdit|LINK
as an experiment i decided to port dnn to a win32 using webservices. but i wanted my client app to use the cbo that dnn uses, and so took on a even greater experiment,
using webservices it was a kodhedz peice of cake to convert the current dataprovider model to operate on a win32, independant of the aspnet limitations. but then to use this in a disconnected model, where the data access was done specifically by the win32
without webservices, involved nothing more than removing the dependencies on cache and other aspnet stuff.
my point, don't knock it too hard. if it can work without much pain ( and much joy!! ) in such a variety of use cases, its pretty flexible. you can't get all at once or you would end up with a banana split cream pie with chocolate double layer and mousse.
to make something too simple or limited is to make it worthless to many in order to make it useful for few. you have to weigh these things and find a good easy medium.
I like the current dal because it forces me to write clean data access code. no unclosed datareaders. no invalid objects. but i also dont like it when it comes to large data sets (in this case, arraylists which are not handled the same by runtime). so
this can potentially end up in memory issues. ever try loading an arraylist of 500 rows of data into a datagrid? the memory is taken up with conversion and is not released for a little while. with many concurrent users, this is an issue.
do the same with a large managed dataset and the results are better, but try it on a separate thread and all of a sudden, the overhead from aspnet is removed and it runs fast fast fast. i stil cannot explain that.
but the performance of smallish/medium arrays are nice. one thing i did notice in the win32 conversion was that to properly serialise the object collections for webservices, the info classes hold their own pretty well, but we need to make a single xmlattbute
to the class for proper serialization into xml. but when it is transferred, the result is an array of the infoObjects, instead of an arraylist. subtle difference, but still a very important one. no type conversion needed, its an array of that type already,
as opposed to a generic arraylist that must be type-defined on each access.
so food for thought, my vote is that we are about 90% there , but the last 10 is fine tuning which always takes a long time, and could end up in a complete overhaul if you dont be careful. but of course, if you want to bore out the pistons, there is always
room for improvement