Memi.Reflection

Private members of memi's thoughts

DataSource controls

I've started diving into the VS2005 beta 1 a few days ago (I hope I'm not the last one...), and naturally started looking at the new features it provides.

While browsing, I've stubmled accross this article in MSDN, which explains the new concept of the DataSource controls. This article made me wonder about this whole new concept.

The SQLDataSource control looks really nice, not to say sexy, but I woner how useful it is going to be in real, full blown applications. I mean, you're not going to write your SQL in its full glory on the ASPX page, don't you? Not to mention the connection string itself. What happened to the n-tier architecture? I don't really see a scenario in my company when I'm going to use this control, except maybe for some really tiny make-it-done-in-two-days applications.

The ObjectDataSource looked more promising, until I've read the small letters. The source object has so many restrictions (default, parameterless constructor, stateless, easily mapped to update, insert and delete actions), but what really caught my eyes are those two:

1. The update / insert methods in the object are expected to accept named parameters. Hey, where did that come from? I've been taught that the best way to pass parameters between layers is by using some general purpose package, may it be XML, named value collection, or even arraylist. If I'm going to add new parameter - why do I have to change my object interface?

2. The method execution is done by reflection. I don't remember where I've read it first time, but AFAIK execution by reflection can be 400 times slower than regular one. OK, when you think of it, there is no really other way of performing this databinding, but if I'm going to use reflection just to update the business layer, why won't I use some third party's professional O/R mapper, which will update my data layer?

So, am I missing something? I guess it's a bit too early to ask for other's exerience on this subject, but what do you think of it? Which DataSource control will be the real hit? Will this concept be widely used?

Comments

rick said:

I had the same thoughts, but after playing around with them I'm singing a slightly different tune. What the *DataSource controls offer is a provider interface for your databound controls. When you're prototyping an app, you can throw some controls around, connect them to some simple Access DB, and you're set. Later on, you can upgrade to SQL Server, stored procedures, and the SqlDataSource: without changing anything.

As for the ObjectDataSource, I'm not too keen on paying the reflection task, but you should be able to build a custom DataSource that binds to your business layer specifically.
# July 31, 2004 10:24 PM

Thomas Tomiczek said:

::Which DataSource control will be the real
::hit? Will this concept be widely used?

They WILL be used. 95% of the developers out there have no clue about what constitutes a good program - they will eat what they are served.

What I personally mislike about the data sources, is that they are not COMPONENTS anymore. Why does it have to be in the visual part of the page? Makes no sense to me.
# August 1, 2004 12:42 PM

Paschal said:

I share the same feelings. I ranted recently n this stupid idea to include a sql connection string in a ASPX page. This going to be a nightmare for serious people who take a project made by a beginner.
Microsoft is a big marketing machine and what they see is only a way to collect more developers, even if they have to screw a whole professional community. Java guys must laugh now !
# August 1, 2004 12:58 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)