n-tier apps - what to use

[Anders S. Willumsen]

Hi,

I'm implementing a 3-tier app (a shop) for the first time, and would like to
have some of you guys comment on the design. Hope you can help me get rid of
some confusion.

I have a data-tier, business-tier and GUI

In the data-tier I have all my data code - connection to SQL Server, and
getting and pushing data. One methods could be DateReader
GetDataDatareader(string SQL) or DataSet GetDataDataset(string SQL) and
there could be ExeceueNonQuery(string SQL) for any delete or
update-operations. There is only a few methods in this class.

In the middle tier we find all classes related to business objects. The
could be a Client and Clients-class, Item and Items-class and so on. Each
class have a few static methods to create objects. A client might have a
FindClient(id) method, and in the method there could be code to call data
tier and convert a datareader-object to and object of Client.

In the GUI tier where ASP.NET (or a PDA or WinForm or...) is showing info
from the business tier (items could bind to a datagrid), and when a clients
data is updated in a ASP.NET form its a middletier objects fields/property
that's chanced, and a call to an Update-methods in the business tier ends op
with generation SQL an calling ExecuteNoneQuery in the data tier.

Hope you understand my bad English (and my design). How does this design
look to you. Data layer is the only thing communicating with SQL Server,
Business layer is using data layer to get data and update data, and GUI is
only using the business layer. Is that the right way of doing it?

If so - I can see the point of separation data from the GUI, and it makes
sense to you classes to represent the data (easy to send a client a mail -
it just a method on the client-class, and the client object already knows
its on e-mail address). The GUI is now kinda simple to develop - its more
about design than code, and the only code would be validation and "binding"
code.

But doesn't this model "cost" a lot in performance. The alternative could be
to implement the data layer in the business layer (when Client object is
generated the call to SQL Server is in the GetClient-methods - its not
forwarded to the data layer). This should be faster - or what? Is that a
design you could recommend - I mean - whats really the point of a data
layer? Im not gonna replace our SQL Server to another database ( we might
update it - but never replace it)

In short - would it be ok to use a 2 tier app in stead of a 3 tier app?

Hope all this makes sense?

Thanks

[Cor Ligthert]

Anders,

Have a look at this page, in my opinon it gives all answers on your
question.

http://msdn.microsoft.com/library/de...ldntierapp.asp

Where I advice you when you are not with a team not to start with a N-Tier.
In my opinion you will see than soon that when you can not make something,
you create very soon some fast solutions to pass dificulties which make your
N-Tier again a 2-Tier or (3-
Tier when it ASPNET) application.

However the last is just my thought

Cor

"Anders S. Willumsen" <an**********@yahoo.com>

I'm implementing a 3-tier app (a shop) for the first time, and would like
to have some of you guys comment on the design. Hope you can help me get
rid of some confusion.

I have a data-tier, business-tier and GUI

In the data-tier I have all my data code - connection to SQL Server, and
getting and pushing data. One methods could be DateReader
GetDataDatareader(string SQL) or DataSet GetDataDataset(string SQL) and
there could be ExeceueNonQuery(string SQL) for any delete or
update-operations. There is only a few methods in this class.

In the middle tier we find all classes related to business objects. The
could be a Client and Clients-class, Item and Items-class and so on. Each
class have a few static methods to create objects. A client might have a
FindClient(id) method, and in the method there could be code to call data
tier and convert a datareader-object to and object of Client.

In the GUI tier where ASP.NET (or a PDA or WinForm or...) is showing info
from the business tier (items could bind to a datagrid), and when a
clients data is updated in a ASP.NET form its a middletier objects
fields/property that's chanced, and a call to an Update-methods in the
business tier ends op with generation SQL an calling ExecuteNoneQuery in
the data tier.

Hope you understand my bad English (and my design). How does this design
look to you. Data layer is the only thing communicating with SQL Server,
Business layer is using data layer to get data and update data, and GUI is
only using the business layer. Is that the right way of doing it?

If so - I can see the point of separation data from the GUI, and it makes
sense to you classes to represent the data (easy to send a client a mail -
it just a method on the client-class, and the client object already knows
its on e-mail address). The GUI is now kinda simple to develop - its more
about design than code, and the only code would be validation and
"binding" code.

But doesn't this model "cost" a lot in performance. The alternative could
be to implement the data layer in the business layer (when Client object
is generated the call to SQL Server is in the GetClient-methods - its not
forwarded to the data layer). This should be faster - or what? Is that a
design you could recommend - I mean - whats really the point of a data
layer? Im not gonna replace our SQL Server to another database ( we might
update it - but never replace it)

In short - would it be ok to use a 2 tier app in stead of a 3 tier app?

Hope all this makes sense?

Thanks