WPF/Layered Architecture 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 b开发者_运维知识库usiness 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

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).

Totally agree with Brian. The way I would normally architect it would be to have web services from the client to the business logic on a seperate server, it makes it extenable but it all really depends on how robust the system needs to be.

Also think about deployment, it would be easier deploying to 1 server than rolling out to all clients. What are the chances of different clients running different versions of the business logic?

Well, I too totally agree with Brian and Burt. "Different clients running different versions of the business logic" is really makes sense.

Basically, Separation on Concerns (SoC) is most important point to allow any application to scale enough for extending it for future needs. As an architecture you should at least perceive this and build some ground work.

Most of today's applications are not monolithic and not remain unchanged. The business requirements are changed so rapidly hence they will need changes in the application too.

Separating changeable things from unchangeable is Important while designing the apps to allow easily extend them.

HTH