Any reason not to use Visual Studio 2005 Data Wizards?

[SoftwareEng]

Visual Studio 2005 (VB.NET specifically) has very powerful data-connection wizards to bind your app's forms or individual controls to the database. Is there a reason not to use this feature? I am saving form's data to a DB; reading from DB into the form, etc.

thanks!!

 

[torpid]

I haven't assessed the VS 2005 wizards, but in past VS versions, there were major reasons not to use them relating to proper layering of your architecture and the like. It's generally frowned upon to have connection info on the page / form itself unless you are doing a quick and dirty app.

With VS 2005 I know they have the whole DB provider model. Not sure how that plays into the data wizard picture...

 

[SoftwareEng]

The new data wizard write a LOT of code, but you'd write 20% of it anyway to get a high-level obj-oriented access to your data.

so, who here is a wizard expert? =)

 

[kamper]

It all depends on what sort of development you want to do. I personally dislike stuff like that from a pure coding perspective because it really takes a lot of power away from the programmer, but there are a lot of business reasons for doing it. I know my dad has been using that sort of stuff in a very large financial environment for a number of years and it works for them but he sometimes gets frustrated with the bloat and the fact that he can't see what's really going on.

 

[Jaxidian]

My assessment of these are that if you're looking to do some RAD (rapid application development) and you care much less about performance than you do about getting a product out asap, then the're very useful. If you're looking for something that is optimally written and properly architected, then I think their primary use is for helping you with templates and that's about it.

Reasons why they are good for RAD:
1. Give me 5 minutes and I can have a page that allows a user to read (from a paged/sortable view) from the table in a database and update any cell of that table.
2. You can do the above with almost pure drag/drop + adding in a connection string.
3. There's a neat feature that you can tie into the above called "Optimistic Concurency" that, almost for free, allows you to have an exception thrown if two users try to modify the same row at the same time.

Reasons why they are bad for "properly" architected systems:
1. Your data access layer is directly tied to your presentation layer. This only allows for a single-tier architecture.
2. While you get sorting/paging for free, it comes at a cost (so I guess it's not for free). Imagine having a table with 30k rows in it that you use this for. Every single time you view a single page (or even sort it), the underlying code actually queries and returns ALL 30k rows, processes ALL 30k rows, then only shows you 10 (or however many you tell it to) of them to the user. That's a LOT of wasted overhead!
3. Perhaps there are more but that's already enough for me to throw out the freebie wizards for any significant *real* projects.

Hope this helps!

-Jax

Edit:
Now don't get me wrong, gridviews and the various datasources can be used in a way that allows them to be very powerful in a properly-architected system. But I really don't know if you can use the wizards very much at all.

Also, something I forgot to mention is that the skinning wizard that comes with a gridview is handy.

 

[SoftwareEng]

thanks guys, Jaxidian in particular

 

[Stuxnet]

I agree with the others. If you're writing an n-tier app, you can't do it right with those wizards.