Question

I’m thinking through the high level architecture of a WPF application.

Usually I would think in terms of this

• A database server
• A data access layer on its own server
• A business logic layer on its own server
• WCF wrapper round the business layer
• UI Layer for use on the client.

E.g. a thin client with all the magic happening on remote servers.

But someone on the team has questioned whether the business logic layer needs to be on a remote server. Why not just roll that onto the client as well, making it less of a thin client and more of a fat client server application.

We have no need for WCF at the moment and assuming we still architect the business logic so it is on a seperate layer this makes some sense to me in terms of simplifying the infrastructure.

My question is… are there any good arhcitectural reasons NOT to roll out the business logic layer to client machines along with the UI layer when webservices are not required?

I can think of drwabacks but none of these seem that big

• Less need for updates on client (but surely clickonce mitigates this)
• More load on client machine.
• Need to ensure database server is chunky enough and connection to it big enough

Answer 1

I would normally separate out the business logic from the UI. Why ? Because your UI may only be one client of that service.

At the moment your client is the only consumer of that service, but at a later stage you may wish have additional clients (including other services) using it. By separating out the business logic, you can then make it available for other consumers.

I would normally make the business logic a component, and then I can choose how to deploy this (in the client, or in a server). In many cases I can’t do that, however. e.g. if the client and server are implemented using different technologies (C#/Java is a common combination).