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.
"Ronald S. Cook" <rc***@westinis .com> wrote in message
news:eC******** ******@TK2MSFTN GP05.phx.gbl...
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
