Should Rich Client Arch be used in Multi Tier Enterprise Systems

Question

We have a fairly large enterprise, multi-tier, multi-layer solution built on .Net 3.5. The system is a Service Oriented Architecture (WCF Services) with an ASP.Net MVC User interface fronting it all.

Some of the guys in the team are working on Tooling for the system, and are implementing these as WPF Rich Client Architectures that connect directly to the database (or other data sources).

Somehow this just does not feel right to me for the following reasons:

1. This would require that the SQL Server would need to be accessible by a number of machines (who are running the tools) directly. Isn't it best practise to only ever allow your application Tier to connect to the database tier? Pass-through authentication will be used anyway for auditability so the overhead of managing multiple login accounts is not an issue.
2. Duplication (or at least distribution) of the business logic would have to occur. Instead of hosting the business logic on the server to be reused, it would have to reside on each of the client machines.
3. Maintenance of multiple client installations: Now all these machines have to be updated separately every time a new version of the tool is released. Okay, you could still use something like one-click to keep it automatically updated.

etc., etc.

I suggested a Rich Internet Architecture for the tools so that we could make use of the extended functionality that the client machines can then supply (which the browser may not be able to do or would just be that much harder on the browser). At least in this scenario the main business logic would still be held in the services layer on the application servers, and there would be no need for any direct connections to the SQL Servers.

I can understand using Rich Clients for applications like word or excel, but if you already have a complete multi-tier solution, surely it's not the best way to do it?!?

I'd like to get a good discussion on the topic going since I don't think this is one of those things that can easily be answered by one line responses (I may be wrong ;-).

What do you think? What have you guys experienced in the past? Where can I find resources to prove or disprove my points above?

---

See also: Google Earth - Rich Client or Rich Internet Architecture?

Answer 1

Yes they could/should be used!. To comment on your reasons:

1. No, that was the original role of SQL server. Multiple applications connecting to the same database. This was very common in the 90s with intranets where multiple standalone apps used the same db. Databases support this very well and this is the reason they have so much security granularity for user accounts (and also views, constraints e.t.c). The "only app server talks to DB" is a newer pattern started in the last 9-10 years
2. Yes you are right. The recommended way to solve this is that standalone clients hit the business logic components of the server application and not the db directly. I don't know about .NET but in J2EE this would mean hitting the EJB or using RMI/Web services.This way business logic code exists only once (in the server).
3. Again you are right but again this is solvable. In the J2EE world this is solved with Java Web Start so I guess that something similar works in .NET.

I have used this pattern (Web Application + multiple standalone applications that hit the application server with web services) in real world applications and it works just fine.

Answer 2

If you have a service layer with any significant logic then I feel that it's quite dangerous to bypass that to go direct from RIA UI to the database.

It's clearly a trade-off, from UI developer's perspective they feel like they may feel like they deliver value quicker, and possibly in the short term see somewhat better performance.

Longer term I think that you tend to see duplication of implmentations of busines logic across the UI layer and between UI and service layer, and you can miss out of performance optimisation opportunities offered by caching in the service layer.

I've had what I saw as considerable success is developing reusable services in the service layer that could be accessed from several different UI implementations. I'm very comfortable that RIA + service is a good, scalable architectural pattern.