Need advice: Stored Proc vs SQL Code vs GUI

[Cirene]

I am working on an ASP.NET 2.0/SQL Server enterprise application which is
basically a online scheduler (like Outlook functionality.) There will be
many simultaneous users hopefully.

For my sql related tasks I was thinking that most of the work can be done
using Visual Studio's GUI Wizards (drag/drop, etc...) without writing any
SQL related code.

Is there any benefit to choosing to write stored procedures or inline SQL
code (like in a DAL class) over simply using the GUI to do the "code"?

I hope I asked this correctly.

Thanks!

 

[Cowboy \(Gregory A. Beamer\)]

I am working on an ASP.NET 2.0/SQL Server enterprise application which is
basically a online scheduler (like Outlook functionality.) There will be
many simultaneous users hopefully.

For my sql related tasks I was thinking that most of the work can be done
using Visual Studio's GUI Wizards (drag/drop, etc...) without writing any
SQL related code.

Is there any benefit to choosing to write stored procedures or inline SQL
code (like in a DAL class) over simply using the GUI to do the "code"?

Yes. Separation of concerns.

You have a UI of some sort (web, it appears, since you posted here), some
business logic and data logic, along with physical data storage. Each has
its own purpose.

When you drag and drop UI code, you marry the UI to the database you are
using. This may be okay in your case, but you should be making a conscious
decision to bind the layers together in this manner.

 

[sloan]

As previously illuded to, you'll have this "marrying" of hte
layers/concerns.

If you actually do this, then I would suggest not calling it an " enterprise
application ".

I would call it a "hobbyist application that my enterprise is going to
use"...because that RAPID development model of drag/dropping isn't good for
maintainable code.

...