Philosophical question about separating tiers

[Ronald S. Cook]

We have a Windows app which contains UI code and all classes that perform
business logic and make calls to database stored procs (located on a
database server - i.e. not local to the app).

My boss wants to bring all those classes to a business server and out of
each instance of the Windows application (i.e. separate into a business
tier).

I understand that by having the business tier separate from the user tier,
we can make changes without having to republish the application. But is it
worth it? With ClickOnce, publishing updates is now very simple. And, to
have the business components on a separate server, doesn't that necessarily
mean .NET Remoting (which adds complexity)? Or is there a simpler route to
be had? Are there more pros that I'm not thinking of?

Thanks,
Ron

 

[Nicholas Paldino [.NET/C# MVP]]

Ronald,

Tiers in an application are abstractions, they don't necessarily have to
be defined by a physical separation.

Have you asked your boss why he wants to move those classes to a
business server? What kind of benefit are you getting? Distributed calls
are not something that can just be wired up through remoting. The nature of
distributed applications is generally that you want to have large chunky
calls, instead of small, little calls. If you have a business object layer,
and you connect to objects on another server, it will probably be slower
than you expect (especially given that the server should handle the load
from all of your clients now). The reason for this is that you usually set
a good deal of properties on your objects before you actually do anything
with them. This will cause a number of remoting calls to occur.

In reality, you should be making one big call, passing all the property
values to be set.

Also, remoting is pretty much dead, with the advent of WCF in .NET 3.0.
Remoting doesn't have the support for authentication, authorization,
transactions, queued messages, etc, etc that WCF does. I really couldn't
recommend it in good faith given what is on the horizon.

Hope this helps.

 

[Guest]

I suggest you read Lhotka's book on the CSLA framework. It gives in-depth
examples of how easy it is to implement a separate physical tier using
remoting. Another option is to expose your classes via XML Web Services
(asmx files in a ASP.NET application).

 

[Greg Young]

A few other benefits that you do not mention here are security and
scalbility.

If you are pushing your business objects/data access code to every machine
every machine will be accessing the database. This obviously brings up some
scalability issues as you get into many clients.

There is also a security issue here as all of these machines need to be able
to contact the SQL server. By putting this to a remote system, only that one
machine needs to be able to contact the SQL server (so you have further
isolated the SQL Server from possibility of attack).

Further security arguments exist due to the ease of disassembling code
(introducing your own code) on the client side. By placing the business
logic on its own server you can host code there knowing it is in a
controlled environment.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

 

[Andy]

Ron,

I'll echo another posters suggestion to look into the book Expert C#
Business objects (there's a second edition which targets .net 2.0, the
first edition is for .net 1.1). There is a huge advantage to splitting
up your application into tiers which can also be physically seperated.
One of those is scalability. The second is that you can easily build
new UIs which reuse the same business level code. So when you need to
go to WPF in the next few years, you won't have to throw out some or
most of your application (it depends on how tightly coupled your
business logic is to your current UI). By providing seperate physical
tiers, you ensure that you aren't 'mixing' business logic, UI and data
access. Csla provides a great framework to build your business
applications on (and if you do, you'll be able to easily use .Net
databinding for building out your UI).

HTH
Andy

 

[Kevin Spencer]

Whether your business classes exist in the client or on the server, the fact
is that if the database or data store is on a server somewhere, the client
still has to access the data remotely. That is, the data must get to the
client in order for the client to present it to the user.

Separation of business logic and UI logic is logical, as the same data may
be presented in various ways using various interfaces. However, that
separation is not physical (as Nicholas pointed out), but in a sense,
abstract. Yes, the classes should reside in separate DLLs, so that they can
be used in other applications. Does putting them on a separate machine
enhance the application? Probably not.

Changes in an application generally percolate upward from the data layer to
the UI layer. That is, if the data layer changes, as the business objects
are clients of the data layer, it is possible that they will have to change.
If the business layer changes, the client, being a client of the business
layer, may have to change. But good separation prevents having to change the
"lower" tiers when changes are made in the "upper" tiers.

The consequences of putting your business classes on a single server are
many, and may be both good and bad. In a single-client UI environment, the
logic is encapsulated in an environment in which it doesn't have to keep
track of which client it is doing work for. When a single server object
services many clients, complexity ensues. The business tier must then keep
track of which client is doing what, and it must perform a large varety of
tasks for a large number of clients concurrently, thus adding complexity to
the application. This also affects performance, as a single instance of the
business logic is now serving many client applications. In essence, when you
put the business classes into a server environment, all handling all clients
at one time, you must add another layer, a "client interface" layer, to
manage all of the clients. The greatest benefit is that there is only one
copy of the code in one location. But, as you have pointed out, there are
plenty of ways to publish changes (new versions of DLLs) to multiple client
interfaces, such as ClickOnce.

In conclusion, I would have to say that, unless one is developing a
deliberately thin-client application (such as a web application) for the
reasons that thin-client applications exist, the only real requirement that
makes sense is to put the data store in a single location, as that is shared
by all clients, and that is what must be coordinated between all clients.
Putting the business logic into a single location is more likely to be
counter-productive than beneficial.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

Big thicks are made up of lots of little thins.