newbie with newbie questions

  • Thread starter Thread starter JohnE
  • Start date Start date
J

JohnE

Hello. I hope to have the correct newsgroup. I have been informed that I
will be moving an Access db (front only) over to a webapp. I have been
"playing" around with VS2008 and an ASP.Net 3.5 book and have some questions
concerning webapps. So pardon me if they are simple. Mainly, the questions
are seeking thoughts and opinions rather then the problem solving this
newsgroup does. The webapp will need to be scalable for future updates,
enhancements, modifications, and additional projects.

1) Is it better to use the connection wizards for the different data
controls or better to manually code it (using C#) in the code behind the
control with ADO.Net?

2) Is it okay to mix ajax controls with non-ajax controls on a web page?

3) My preference is to use stored procs whenever possible rather then
coding the sql into the code. Is this the best technique?

Thank you for your time on this. I may have other questions as I continue
to forge ahead on this project. I do need to say, that from what I have done
so far just "playing" with the webapps in VS2008, it will be exciting and I'm
looking forward to it.

Thanks ... John
 
Mr Rae, thank you for the responses.
.... John



Mark Rae said:
"Better" is impossible to answer. My preferred method is to use a Database
Abastraction Layer (DAL) and call it from code every time I need to
interface with the RDBMS. Microsoft has a good starter example of this:
http://www.microsoft.com/downloads/...8B-2986-47F7-B529-3E41584B6CE5&displaylang=en
As you're just starting out, the practices and patters described there will
stand you in good stead.

As a general rule, I never go anywhere near any of the "training wheels"
wizard controls (data access, validators etc)...


Again, "best" is impossible to answer. Most developers perfer stored
procedures over dynamic SQL for many reasons...

Tip: don't let anyone tell you that every table in your database absolutely
*has* to have its own INSERT, UPDATE, DELETE and SELECT stored procedure -
and especially don't let anyone tell you that every table in your database
absolutely *has* to have its own class and/or table adaptor in your web
app...
 
Hello. I hope to have the correct newsgroup. I have been informed
that I will be moving an Access db (front only) over to a webapp. I
have been "playing" around with VS2008 and an ASP.Net 3.5 book and
have some questions concerning webapps. So pardon me if they are
simple. Mainly, the questions are seeking thoughts and opinions
rather then the problem solving this newsgroup does. The webapp will
need to be scalable for future updates, enhancements, modifications,
and additional projects.

My answers will be somewhat different from Mark's, but that is probably
what you want in a group like this.
1) Is it better to use the connection wizards for the different data
controls or better to manually code it (using C#) in the code behind
the control with ADO.Net?

Like Mark, I prefer a DAL in a final app. Unlike Mark (I think,
certainly unlike sloan), I will often use the drag and drop bits to get
things started.

My current preference is LINQ to SQL in a DAL, as it is quick and easy.
I have a blog entry (http://snurl.com/qdsiy) which uses a DAL with LINQ
to SQL. It is a partial implementation right now, but will be more
fettered out shortly.

2) Is it okay to mix ajax controls with non-ajax controls on a web
page?

Sure, but architecturally make sure you are not mixing metaphors. What I
mean here is, for maintenance, you are better to use one transport
mechanism. If you use AJAX as helpers, but save via PostBack, you are
fine. If you use AJAX to load and save and all helpers, you are fine.
When you start using AJAX to save some times and a form submit others,
you end up with an overly complex architecture that is hard to maintain.

3) My preference is to use stored procs whenever possible rather then
coding the sql into the code. Is this the best technique?

if you have a lack of confidence in changing your database schema,
sprocs are preferred, as you can completely alter the database schema
without altering the interface.

What you end up doing here is abstracting out the interface to your
database.

Depending on the app, I often shoot for sprocs as my abstraction layer,
as well. Read up a bit on sprocs to ensure you are not writing SQL that
has to recompile all the time. It is time well spent.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
The way I do it is that I have a DAL which is a DAL and nothing but a
DAL.

As such, it can be dropped into any .NET app (WinForms or WebForms)
*completely* unmodified. The only exception to this, of course, is if
a new project needs to support a backend RDBMS which my DAL doesn't
currently recognise. At that point, it would be a fairly trivial job
to add support for the new RDBMS into the DAL's factory pattern...


I will drag and drop on the forms and then neuter all of the plumbing
crap. The form is done in a minute or two, with a minute or so of
neutering.

As far as DAL, I create one and reuse often. I have a generic LINQ to
SLQ thing I am playing with now. ;-)



--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Back
Top