Separating presentation from data layer

[Michelle]

Hi all... I could use a little TLC here for understanding and not for
solving a specific problem... sorry if I've got the wrong group, but I'm
using VB so I figured this was the most appropriate one.

I'm an advanced beginner, but in all of the books and class material I have,
I haven't found something that gets to the point about this... lot's of high
level theoretical talk, but nothing that says things in simple terms.

I'm building an app and want to separate the presentation and data "stuff".
Here's some background on the approach I want to take as I understand it:

In my VS project (an ASP.NET project), I've got 3 important things:

1) Submit.aspx -- this is the presentation "thing". It contains mostly
just web controls. Textboxes, a DateTime control (from a vendor), labels,
and a submit button. For example purposes, let's say the fields are:
FullName, PhoneNumber, DOB.

2) DataLayer.vb -- this is my "data" stuff. It contains a class called
"User" that is a model of the data in my form. So, there are read/write
properties for FullName, PhoneNumber and DOB. Also, there's a method called
"SaveToDB" that does exactly that--- opens a database connection and Inserts
the data into a table.

3) Submit.aspx.vb -- The code-behind for Submit.aspx... there's an event
handler here for the Submit button that:

- instantiates an object based on the User class
- sets the properties of this object using values from the web controls
- calls the SaveToDB method on that object to write the values to the
Database.

My questions are:

1) I might also like to write a couple of other classes, possibly to handle
validity... is it appropriate for me to write them in the DataLayer.Vb? My
confusion is because in Visual Studio, when I add a new item, it refers to
it as a "Class"... is this only supposed to contain ONE class?

2) Is this approach reasonable--- I know this is a small app... just an
example, but if it were a lot bigger (i.e. more controls on the form, more
fields, etc), would this be the right approach? If not, what am I doing
wrong?

3) In an app like this, where you are submitting information in a form, is
it better to postback and hide the form to display success, or is it
considered better practice to submit to a second page and have that page
call my data layer?

Thank you in advance for your time...

Michelle

[Cor Ligthert [MVP]]

Michelle,

That second page should be the components I described. Pages are only for
communication with your clients in this approach.

If you hide parts or use response.redire cts depends in my opinon how much
the form changes.

However in my opinion should the datalayer never be a page.

Cor

[Michelle]

Not really what I meant...

In books, I've seen examples of forms based apps where when you click the
submit button, it hides the form and displays a message rather than what
I've seen in a class asp app where it would use a post to another asp page
which handles the data work and displays a message...

Something like:

' this is on the "data entry form" page
' Panel1 on this page contains the data entry controls (eg: textboxes, etc)
' Panel2 contains a label that says "Congratulation s, your data has been
added to the database"

Sub btnSubmit_Oncli ck(ByVal sender As System.Object, ByVal e As
System.EventArg s) Handles btnSubmit.Click
' call the class that does the data work here
Panel1.Hide
Panel2.Visble
End Sub

So is this a normal approach?--- my instinct would be to eliminate the 2
lines that hide and display the panels, but then redirect the user to
another page that displays the message...

M
"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:Od******** ******@TK2MSFTN GP10.phx.gbl...

Michelle,

That second page should be the components I described. Pages are only for
communication with your clients in this approach.

If you hide parts or use response.redire cts depends in my opinon how much
the form changes.

However in my opinion should the datalayer never be a page.

Cor

[Michelle]

oops... third line should say "...seen in a classic asp app..."

M

"Michelle" <Nope> wrote in message
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Not really what I meant...

In books, I've seen examples of forms based apps where when you click the
submit button, it hides the form and displays a message rather than what
I've seen in a class asp app where it would use a post to another asp page
which handles the data work and displays a message...

Something like:

' this is on the "data entry form" page
' Panel1 on this page contains the data entry controls (eg: textboxes,
etc)
' Panel2 contains a label that says "Congratulation s, your data has been
added to the database"

Sub btnSubmit_Oncli ck(ByVal sender As System.Object, ByVal e As
System.EventArg s) Handles btnSubmit.Click
' call the class that does the data work here
Panel1.Hide
Panel2.Visble
End Sub

So is this a normal approach?--- my instinct would be to eliminate the 2
lines that hide and display the panels, but then redirect the user to
another page that displays the message...

M
"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:Od******** ******@TK2MSFTN GP10.phx.gbl...

Michelle,

That second page should be the components I described. Pages are only for
communication with your clients in this approach.

If you hide parts or use response.redire cts depends in my opinon how much
the form changes.

However in my opinion should the datalayer never be a page.

Cor

[Cor Ligthert [MVP]]

Michelle,

Do not mix up classic asp, windowsform and aspnet with each other, they need
all three different approaches. You could not do with ASP what you can do
with ASPNet and you cannot do with ASPNET what you can do with Windowforms.

I opt in most cases for the dual panel where you use your sample because it
gives me a cleaner application. But both ways are valid.

However this has nothing to do with the data layer.

Just my thought,

Cor