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,

As this is a general approach question, here some general answers.

A dotNet webapplication with data is basicly direct starting a 3 tier
application.

Tier 3
The page (aspx), that is from the middle tier generated HTML page which is
processed by the webbrowser of the client and which communitace with your
database.

Tier 2
The DLL, that is created for handling the request and answers and is for all
users at the same time active

Tier 1
Your database.

You are in fact all the time in dotNet webdevelopment busy with Tier 2. The
client tier is generated from that while the database exist.

If you are building the application (the DLL), than you should in my opinion
be stupid not to do what you say.

Create all database access in a seperated components (classes) for this (and
add than the item component to your IDE for this.

However be aware that all data in that class if you set it shared, will be
shared by all users.

Therefore I would make in your situation at least two (data) classes.

One to share all non updatable date (addressbooks, article lists, etc) by
all clients, without consequently updating.

One (or more) to use as a helper class, to use for all your database
handling. That one you have to create every time as new object from this
class in the UI's that it uses. This because the data of a handled web page
will go completly out of scoop if the generated page is (again) sent to the
client. (A webform is not persistent)

I hope this gives some idea.

Cor

 

[Michelle]

Cor:

Thanks for taking the time...

Can you explain your last 2 paragraphs?--- it's unclear to me what you're
suggesting. Do you mean one class file (eg: readData.vb) that does just
read operations from the database, and one class file (eg: updateData.vb)
that handles only Insert, Delete and Update operations?

Thanks,
Michelle

 

[Cor Ligthert [MVP]]

Michelle,

No one of the actions is to create a shared class for all your consistent
data you use in your pages. Than you can do that one time.

Just ask in the creation of that ( if a datasource is nothing)

Than your pages have only to load that data in memory once

You cannot use that in data that has to be updated (or it should be in a
very difficult way).

The objects from that will you have to be created everytime new at pageload.

I suggest you to use seperated classes for those.

I hope that this gives an idea

Cor

 

[Cor Ligthert [MVP]]

Previous was at least for me unreadable

No one of the actions is to create a shared class for all your consistent
data you use in your pages. Than you can do that one time.

Just ask in the creation of that ( if a datasource is nothing)

No, one of the classes is for the handling of all your consistent data,
that you use in your pages. Than you can do that one time. To prevent all
the time reading. Because that if all sessions are stopped, than it closes,
you can just ask in the creation of that if a datasource is nothing and
than do all handling to get the data again. (Be aware that if it is real
active you have to time by time to close by hand, a simple aspx page can do
this job)

The other one is than for regular client data handling, or you create more,
however don't splits the reading and updating, I will earlier do that for
the different datasets that be used

I hope this gives an idea

Cor

 

[Michelle]

Cor... thanks... I think I'm understanding. Let me answer my questions
based on what I understand from your words:

Not only is it acceptable to have more than one class in a Class file,
it is a sensible approach.

Creating separate classes to handle data operations is a reasonable
approach, and considering the example, it may be beneficial to have more
than one class to handle data: One that performs read operations and
possibly even caches information in the session object, and a three others
that handle Insert, Update, and Delete operations -- these classes should
handle the connection to the database as well (separating that operation
from the PageLoad event).

No answer provided yet.

 

[Greg Burns]

Not only is it acceptable to have more than one class in a Class file,
it is a sensible approach.

Jumping into the middle of this, sorry.

You can have more then one class inside a *.vb file. But most (by most I
mean me) don't do this. It adds a layer of confusion.

IMO
Greg

 

[Cor Ligthert [MVP]]

Michelle,

The only thing I will add is use a component (which you can add from your
solution explorer as item) for your dataclasses. That component has all
build in for disposing etc. It seperate directly your data from your pages
(I will not call it here UI, because it is not the UI, it is a kind of
middle tier) Although the DLL is one so it is in fact all the time in one
application.

I hope this is enough for today?

Although be free to ask again as you have all thought over, this newsgroup
is not closing you know



But I hope as well that it helps

Cor

 

[Cor Ligthert [MVP]]

Reading Gregs post.

For every class another component, otherwise it has no sense at all (while I
completely agree what Greg wrote)

Cor

 

[Michelle]

Any thoughts on the third question: -- In an app like this, where you are
submitting information in a form, is
it better to postback to the same form "on submit" and hide the form
elements (eg: in a panel perhaps) to display success, or is it considered
better practice to submit to a second page and have that page
call the data layer?

Thanks,

M

 

[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.redirects 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 "Congratulations, your data has been
added to the database"

Sub btnSubmit_Onclick(ByVal sender As System.Object, ByVal e As
System.EventArgs) 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

 

[Michelle]

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

M

 

[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