Architecture Advice

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm going to be using SQL Server (thanks for that advice) for a distributed
application and I'd appreciate any advice on architecture.

The application is similar to a membership management system at a multi-site
chain -- like a fitness center chain.

Tasks include:
- Add new member - from any site or over the web
- Edit member
- Sign in/confirm member - at a location (enter ID, confirm photo)
- Reporting
- Etc.


Simplest approach would be 2-tier client server and be done with it.

However, it would be nice to be able to provide some data caching at the
sites, so we can do some basic tasks if the network goes down -- like sign in
a member.

And I can see some benefit to having the client apps isolated from the
database itself in case we ever want to move away from SQL Server, although
that's not a central design goal.


Any suggestions or experiences that might steer me to one solution or
another? Candidates include:

1. 2-tier client/server
2. middle tier on the server accessed with .net remoting
3. middle tier distributed at the sites that includes some data caching
4. distributed database using replication when network is online
5. others I'm not thinking of

Thanks for any war stories / advice!
kc
 
kcamhi said:
I'm going to be using SQL Server (thanks for that advice) for a distributed
application and I'd appreciate any advice on architecture.

The application is similar to a membership management system at a multi-site
chain -- like a fitness center chain.

Tasks include:
- Add new member - from any site or over the web
- Edit member
- Sign in/confirm member - at a location (enter ID, confirm photo)
- Reporting
- Etc.


Simplest approach would be 2-tier client server and be done with it.

However, it would be nice to be able to provide some data caching at the
sites, so we can do some basic tasks if the network goes down -- like sign in
a member.

And I can see some benefit to having the client apps isolated from the
database itself in case we ever want to move away from SQL Server, although
that's not a central design goal.


Any suggestions or experiences that might steer me to one solution or
another? Candidates include:

1. 2-tier client/server
Click to expand...

---Considering how easy it is to create true n-Tier components in .NET,
unless this is a small app that won't grow, I'd build it n tier.
2. middle tier on the server accessed with .net remoting
Click to expand...
--You have two basic approaches, .NET Remoting/COM+ or Web Services.
Web Services are built on top of .NET Remoting so for performance,
you're going to get more out of Remoting, and TCP over Binary is going
to be notably faster that using WS which entails SOAP over HTTP
3. middle tier distributed at the sites that includes some data caching
Click to expand...
--This isn't mutually exclusive from #2. I'd definitely look to
caching. Check out the Caching Application block for some really good
ideas on how to implement it
4. distributed database using replication when network is online
Click to expand...
--Not sure I follow you on this, as opposed to what for instance?
5. others I'm not thinking of
Click to expand...
For this, I think using Remoting and making it NTier is your best bet.
Remember that all you have to do to make it remotable is inherit your
classes from MarshallByRefObject. You can also host your components in
IIS for instance, and using interfaces on the client, you can have a
system that will allow you to drop in new DLLS and you won't have to
touch or recompile your client/middle teir components. You can handle
all such issues through config files. Also, you can split up your
components so that everything is remotable so you can split the load
over multiple machines. If you don't need/ want to up front, then you
can load everything on one machine (so it's client/server). Then if
the base grows or you need performance/security associated with
splitting things up, it's literally only a matter of copying files and
chaning config file settings - nothing else. This is huge.
Thanks for any war stories / advice!
kc
Click to expand...

HTH,

Bill
 
Kcamhi,

Be aware that an ASPNet application with ADONET is forever a 3Tier.

The browswer is your Client UI which is independent from any other client
The DLL created by ASPNET is your middle tier which interact between your
clients and the data
The Database server is your dataaccess tier.

This does not mean that you can connect in your middle tier to other tiers
as Bill showed by instance by using remoting.

Just as addition.

Cor
 
Cor,

That hardly qualifies the application to be 3 tier. Would you also then
argue that because .NET sits on COM which sits on Win32, which sits on
Assembly and IRQs, all of those are layers? What is the definition of a
layer per you? The two definitions I've heard are physical and logical. And
an ASP.NET app out of the box is hardly a 3 tier application by any stretch
of imagination.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Sahil said:
Cor,

That hardly qualifies the application to be 3 tier. Would you also then
argue that because .NET sits on COM which sits on Win32, which sits on
Assembly and IRQs, all of those are layers? What is the definition of a
layer per you? The two definitions I've heard are physical and logical. And
an ASP.NET app out of the box is hardly a 3 tier application by any stretch
of imagination.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
Click to expand...
Sahil - I agree with your assessment but I guess it all depends on how
you define layers. Typically I'd think of it in terms of an appdomain
or an executing assembly. With IE it's just a conduit, everything is
executing on the server so it's not the same as having a winforms app
which consumes a dll remotely which calls some DALC remotely.
Ultimately I guess it depends on how you define tiers but I'm in
agreement with your definition here.
 
Thanks Bill - that's very helpful.


W.G. Ryan said:
---Considering how easy it is to create true n-Tier components in .NET,
unless this is a small app that won't grow, I'd build it n tier.
--You have two basic approaches, .NET Remoting/COM+ or Web Services.
Web Services are built on top of .NET Remoting so for performance,
you're going to get more out of Remoting, and TCP over Binary is going
to be notably faster that using WS which entails SOAP over HTTP
--This isn't mutually exclusive from #2. I'd definitely look to
caching. Check out the Caching Application block for some really good
ideas on how to implement it
--Not sure I follow you on this, as opposed to what for instance?
For this, I think using Remoting and making it NTier is your best bet.
Remember that all you have to do to make it remotable is inherit your
classes from MarshallByRefObject. You can also host your components in
IIS for instance, and using interfaces on the client, you can have a
system that will allow you to drop in new DLLS and you won't have to
touch or recompile your client/middle teir components. You can handle
all such issues through config files. Also, you can split up your
components so that everything is remotable so you can split the load
over multiple machines. If you don't need/ want to up front, then you
can load everything on one machine (so it's client/server). Then if
the base grows or you need performance/security associated with
splitting things up, it's literally only a matter of copying files and
chaning config file settings - nothing else. This is huge.

HTH,

Bill
Click to expand...
 
Bill,

For me a tier processes its data independend from another assembly.

This is a complete different from a layer which is in fact a connected part
of the assembly.

I have seen often told that a layer is a tier, which is in my opinion
absolute not true.

Remoting is for me a typical sample from what is using a extra tiers.

In an ASPNET application are all actions by the way exectuted in ASPNET on
the browser. (It only asks to start a process as to refresh the data or
whatever on the server) If you open the source in your browser from an
ASPNET application than you can see how much scrambled and not scrambled
Javasctript is in that.

Cor
 
Cor said:
Bill,

For me a tier processes its data independend from another assembly.

This is a complete different from a layer which is in fact a connected part
of the assembly.

I have seen often told that a layer is a tier, which is in my opinion
absolute not true.

Remoting is for me a typical sample from what is using a extra tiers.

In an ASPNET application are all actions by the way exectuted in ASPNET on
the browser. (It only asks to start a process as to refresh the data or
whatever on the server) If you open the source in your browser from an
ASPNET application than you can see how much scrambled and not scrambled
Javasctript is in that.

Cor
Click to expand...
I'm not sure I follow you though. My point earlier was simply that it
all depends on how you define a tier but in standard parlance, a simple
aspnet app isn't considered ntier. Again it depneds on definition.

In an ASP.NET app, all the actions aren't executed in a browser, on the
contrary, other than client side script, it all executes on the server.
HTTP is stateless so it has to execute in a completely disconnected
fashion. So in traditional lingo, the web server itself is the client
and makes remote calls to a db or app server. In a remoting scenario
that can change although it depends on where you host the assemblies.
But when most people talk of 3 -Tier it's a reference to the UI layer,
the application layer and the db layer. THis can be expanded greatly
with remoting/web services but that's traditionall what's meant.
 
Bill,
In an ASP.NET app, all the actions aren't executed in a browser, on the
contrary, other than client side script, it all executes on the server.
Click to expand...

You can almost completelely do your verification against business rules do
in the browser, it is what you prefer. That client side script is processing
you know. For me that is exactly what tiers do, seperate the processing
parts assynchronous from each other.

It seems maybe for you not that way because it is so easy to do with an
ASPNET application. It generates in the most simple way for you standard a
complete UI in the browswer. Which is not the same as the code that you have
made.

However feel free to have another opinion than me.

Cor
 
But the business rules seldom occur client side. Sure, client side
validation of controls occur but you can have an ASP.NET application without
javascript or any client side scripts. That's why you need to check for
post backs, b/c a trip is made back to the server where everything happens.
Again, it's probably a difference of definitions but in virtually every
discussion I've ever been in, every presentation and every book, tiers are
defined differently then your definition. I'm not saying it's wrong, but
your original statement that all ASP.NET applications are 3 tier needs to be
clarified b/c by the most widely used definitions of the term, that simply
isnt true.
 
Bill,

As I always write don't misquoute me, I hate it if that is done, you would
know that.
I'm not saying it's wrong, but your original statement that all ASP.NET
applications are 3 tier needs to be clarified b/c by the most widely used
definitions of the term, that simply isnt true.
Click to expand...

I explicitely did not write it in that way.
Sure, client side validation of controls occur but you can have an ASP.NET
application without javascript or any client side scripts. That's why you
need to check for post backs, b/c a trip is made back to the server where
everything happens.
Click to expand...

A postback is a message to the UI messages handling tier which replies (or
not a message) to the UI tier. You wrote in my opinion in fact what the
interaction between tiers is.

Checking can in my opinion be needed in any tier of an application.

Cor
 
Cor - I in no way was trying to misquote you or take your comments out of
context. Here's what you said and this is what I was responding to:

<<Be aware that an ASPNet application with ADONET is forever a 3Tier.>>

Where exactly did I misquote you?
 
Bill,
<<Be aware that an ASPNet application with ADONET is forever a 3Tier.>>

Where exactly did I misquote you?
Click to expand...

You wrote <<I'm not saying it's wrong, but your original statement that all
ASP.NET applications are 3 tier>>

An ASPNET application without ADONET is by instance in my opinion not a
3Tier.

Cor
 
But just so I understand you, you are saying that I misquoted you there?
The presence of ADO.NET doesn't define a teir in any way that I've ever
heard the word and the implication, within the context of what else you said
is pretty clear... namely that a Web app without ADO.NET is still 2 teir
right?

<<An ASPNET application without ADONET is by instance in my opinion not a
3Tier. >> This is precisely the point I'm taking issue with. If you have
a web application that calls a web service or remotes objects, lets say
that you have , for the sake of discussion, 3 application servers so you
remote a string object through three application servers back to the
client - this isn't N-Teir in your opinion? (It doesn't use ADO.NET after
all) . You have your asp.net site call appserver1 which performs business
logic and calls apperver2 which performs some other business logic which
in turn calls appserver3 which handles credit card processing. It sounds
like you're saying this 'isn't' N-Tier b/c of the abscence of ADO.NET. If
that's your point I think you're just incorrect on it.
Click to expand...

Similarly, you can have an ASP.NET application that has all the DALC
components in the same project. Moreoever what if you had no dalc layer,
you just connected to the db directly from your page. Where is the tier?
One project that contains all the business and Data Access logic running on
one machine. Again it sounds like your implying that this is a 3 teir
architecture.

The issue I have is that you're implying that because you're using a browser
that it somehow changes the architecture. What if I ran the app in terminal
services mode? It sounds like you would reason that this is a n-teir
application?

Finally, you can use ADO.NET without ever touching a database. So if you
have a ASP.NET application that uses a dataTable (ADO.NET) to store user
settings, and everything was created/existed in the same project, your
statement <<Be aware that an ASPNet application with ADONET is forever a
3Tier.>> is misleading without clarifying it and that's all my point was.
If you had a one page application in ASP.NET that had one datatable in it
and no other classes - that meets your criteria but it doesn't meet the
criteria of a n-Tier application by any use of the word that I've ever come
across. I've maintained that this whole discussion seems predicated upon
differences in definitions - so if you'd be so kind, I'd love to read where
teirs are differently than they are in all the books and presentations I've
seen.
 
Bill,
. I've maintained that this whole discussion seems predicated upon
differences in definitions - so if you'd be so kind, I'd love to read where
teirs are differently than they are in all the books and presentations I've
seen.
Click to expand...

Books are often parroting. The same way as once is proved in California that
children become from cabbage

Try to see it from my point of view where a windowsform application is
exchanging messages with a remoting service or a webservice. For me a
webbrowser communicating almost the same messages with the DLL created on
whatever webserver (in can as well be the data part of a classic ASP
application by the way, that part is not sent to the browswer, the browser
does there as well only the UI handling).

However feel free to have another opinion with me.

I agree that I had connected ADONET to much with a databaseserver, it can be
with ADONET without a databaseserver (which I see as a separate tier) as
well be a 2Tier application. And with this even more telling that for me an
ASPNET application is not forever a 3Tier.

By the way Tiers and Datalayers are different things for me. I see them
often described as if they are the same.

However feel free to have another opinion about this than me.

Cor
 
Doh,

Tiers and Layers.

I hope you don't mind that I want to stop this thread, I thought that
everything was said.

:-)

Cor
 
Back
Top