Plip's Weblog

Lazycoder weblog » Strongly typed objects and collections vs. performance

aw hell man, they screwed with the webserver againg. here's the correct URL

http://www.lazycoder.com/weblog/index.php?p=51

I agree that designer "should" be able to do everything from the IDE. I also agree that it should automatically generate a high performance system that is also scalable. Until the day comes when what should happen actually does, programmers like us will have to do the work to make things actually work.

I suggest taking a look at a discussion in progress of others who push the dataset, versus me who pushes the custom classes. I've linked to your post to help persuade them, but I think you could do better yourself.

Check it out:

http://objectsharp.com/Blogs/barry/archive/2004/02/10/273.aspx

Doing the custom entity thing is absolutely going to get easier with Whidbey. Firstly you have generics which will make easy work out of "collectionizing" custom entities. The only caveat that I'll repeat here is that your data is stored row-based and not column based so there are performance implications for that.

And then you have objectspaces which will do for custom entities what dataAdapters do for the dataset. I'm looking forward to that for sure - and would have hoped that they supported datasets but from what I saw/heard at PDC - it's not in the cards. There is a performance hurt here right now of twice or more as slow but the goal is to get that down to 30/40% slower than traditional techniques. I do get a bit queasy of not being able to tweak your sql if necessary - but it's certainly an option for teams that don't have or want or need the db access skills.

One interesting thought that I'd like to play out is using a DataAdapter against a custom entity collection. It's a nice pattern of commands for CRUD behaviour and has a mappings collection to boot.

So how do you handle optimistic concurrency with custom entities? I don't see any storing of original values?

I've added a comment to another posting you made here reffering to this: -

http://weblogs.asp.net/plip/articles/111126.aspx#112900

Hey Plip - I'm just about to have the same arguments but seeing as I make the decisions round here - I think I'm going to win. We'll see.

I put up a new article for newbs on Collections and Properties. It meant nothing to the two junior developers here so I figured what the hell.

If you spot any errors or ommissions, let me know
http://weblogs.asp.net/dbarrow/articles/112933.aspx


Cheers
Damian

I couldn't agree more with the ideas proposed here. Passing around opaque datasets filled with unknown data just doesn't scale, and you lose all the advantages of OOP in the process. As for nulls, don't allow them in your schema. Either require a value or use default constraints.

We've implemented a system using .NET custom attributes and Reflection that automagically maps properties to columns that have the same name. All the mapping code is in the base class, so getting a new object working is just a matter of decorating the properties with our custom attribute.

Strongly type objects with polymorphic code attached to them are kinda the whole point of OOP and .NET, no?

I agree, read my post for more insight

I'm pretty close to completing a project where I have used nothing but strongly typed objects. I wanted to test how development would be different to using datasets and datatables.

Part of this involved a system (which sounds similar to what Paul Modzelewski described above) where an xml file held the column name, datatypes and column data size of my database tables i.e. basic metadata, and my Base business object which all of the custom objects were derived took care of mapping data to and from the business object fields using reflection and field level attributes, then sent this 'DataPackage' to the correct DAL object which built the dynamic SQL and command objects from the meta data. Probably not well described but hopefully you get the gist of it.

I have to say - once this was all set up my the development time was slashed by 50% at least and in short I've learnt that really don't need datasets/datatables and the weight which they carry round. I now have a system which uses incredibly light objects which only carry what is needed to solve the problem. A great solution I think which compared to using datatables/sets does away with what amounts to writing wrappers around datatables ect which is a lot of extra work for little benefit.

I hope to stay with strongly typed objects.

one question though, can anyone eloborate on this:

>> and would have hoped that they supported datasets but from what I saw/heard at PDC - it's not in the cards