Multi-tier ASP.net web application

[kito]

Hi,
I've a question, regarding the multi-tier model of designing
applications. I'm programming a web-application (Little web-shop) in
VB.net for a project of the university and my question is the
following:

I have a table "Customer" in the database. Is it intelligent then, if
I'm creating (in the business logic) a VB class called Customer.vb,
which looks like the following:
Namespace Blogic
Public Class Customer
Dim _alias As String
Dim password As String
Dim companyname As String
Dim firstname As String
Dim lastname As String
Dim birthdate As String
Dim street As String
Dim city As String
Dim zipcode As String
Dim country As String
Dim contactTitle As String
Dim email As String
Dim phone As String

Public Sub New()
MyBase.new()
....
End Sub
....
....
End Class
End Namespace

The idea is every time i retrieve data about the customer, I create
objects out of that class, filled with the data from the database and I
pass this object then further to the Top-logic or UI logic??
Or would it be better just to pass the data in some kind of collection,
elaborated in the business logic?

Can someone give me suggestions, since I'm new to ASP.net

Thanks

 

[Kevin Spencer]

Really, it makes no difference what you're storing in the database. If you
analyze the problem, you realize that every database table contains columns
and rows, regardless of what you call it. What I'm getting at here, is that
it is the business rules, the requirements of you app that determine the
structure. It may be logical to create a "Customer" class, or it may not.
For example, if you want to create a tabular interface for working with
Customer records, the extra step of creating a Customer class would be
unnecessary. On the other hand, if you need to apply a lot of logic that
acts upon that data, treating it as a Customer (a human being or an
organization), a Customer class would probably be a good idea.

What you need to do is completely anaylyze the requirements and business
rules of your app, taking into account likely future enhancements and
changes, and design your structure accordingly.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Orange you bland I stopped splaying bananas?

 

[kito]

Yes, ok
thanks

Really, it makes no difference what you're storing in the database. If you
analyze the problem, you realize that every database table contains columns
and rows, regardless of what you call it. What I'm getting at here, is that
it is the business rules, the requirements of you app that determine the
structure. It may be logical to create a "Customer" class, or it may not.
For example, if you want to create a tabular interface for working with
Customer records, the extra step of creating a Customer class would be
unnecessary. On the other hand, if you need to apply a lot of logic that
acts upon that data, treating it as a Customer (a human being or an
organization), a Customer class would probably be a good idea.

What you need to do is completely anaylyze the requirements and business
rules of your app, taking into account likely future enhancements and
changes, and design your structure accordingly.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Orange you bland I stopped splaying bananas?

 

[sloan]

spaces.msn.com/sholliday/

I have a 1.1 and 2.0 "tiered development" example.

Should you create a Customer class? Most times, I'd say yes.
But if all you are doing is creating a web page, with a list of customers,
so you can click "Edit", than maybe not.

But anytime I program something professional or semi professional, I go with
the custom objects.

The articles at the blog reference a microsoft article, I'd find it and read
it.
It gives you the main stream way so handling info, and what it means.
Much better than I could explain in a newsgroup post.

Last comment:
"Rapid Development" is not the same thing as "Good Development" alot of
times.
So it depends on your motivation.
When I'm not less interested in "Rapid", I set up my custom objects.

With 2.0 and generic <List>'s , its alot easier, since I don't have to
create a CustomCollection : CollectionBase for every object I created.

 

[kito]

Yes I normally also create objects for tables like Customers, Products
and so on...But since it is the first time I program a .NET ASP
application, I was not sure. What about memory...
Usually in Java applications, I created objects out of the database,
storing them in some Collection (Array-list) or so....depending which
object than was changed by my program, the object updated itself (with
some corresponding method) to the database. This worked quiet fine, but
I'm not sure if this is the right strategy for a web application.
I think it should be better not to load all data into memory...

thanks anyway sloan

 

[Dave Johnson]

greetings kito,

whtever u were trying to develop, you should first search for n-layer
net applications at google or msdn.

Sharing makes All the Difference