ASP.NET web application architecture design advice

Question

Hello everyone,

previously my ASP.NET web application connects to a database directly using ADO.NET. Now I want to change it to 3 layers, ASP.NET layer, middle web service layer and backend database layer. I think there is benefit that I could abstract data source to ASP.NET front layer, loosely coupled and reduce potential security risks to let external exposed ASP.Net web application to be able to access database directly, etc.

Compared with 2 layer architecture with the 3 layer architecture, I met with 2 major issues.

1. An additional middle web service layer will incur more traffic, e.g. ASP.NET does not talks to database directly, but talks to a web service and the web service talks to thedatabase, will incur more traffic. Will it be a bottleneck? Any general advice to solve this issue if it is a bottleneck?

2. Since ASP.NET can not connect to database but connect to web service, it can not get easily a DataSet/DataTable object. It becomes hard to present table form data to data bound controls. Any ideas to make presentation layer in ASP.NET easier coding?

Regards,
George

Answer 1

If you only think there is a benefit, you should not do it. You are talking about adding a large amount of complexity and work for yourself, at the cost of performance, code simplicity, and architectural simplicity, for... what? What do you gain that's worth these costs?

Do you:

• Have urgent security-related needs that require disconnecting the web front-end from the database server (no, not hypothetical "I bet this would be more secure" but demonstrable, concrete security problems which cannot be solved by being smart about what DB rights you grant your ASP.NET application)

• Expect to swap your data tier out completely at some point in the future (probably repeatedly), and thus need to insulate your web codebase from radical DB changes?

The answer to these in very nearly every case is no. Doing this would just be adding pain for yourself and anyone else who might touch this app.

Answer 2

Regarding your question #2 - you can most certainly return a DataSet from a web service. http://tinyurl.com/ah58xc

However, perhaps a better option would be to simply refactor your application instead of making it into a multi-tier. For example, separate the "data access" into a separate Class Library project that you reference from your ASP.NET project. This could make things more organized and might possibly accomplish some of what you're wanting to do with the multiple tier architecture.

By the way, the biggest danger in creating multiple tiers when you might not necessarily need them is that you end up creating "proxy" code, for lack of a better term. That is, methods that serve no purpose other than to call the "real" back-end methods with the same parameters. This feels better at first because you have a clean layer separation but leads to maintenance problems down the road, because, for example, to add a parameter to a method, you have to add it 3 times (back-end, proxy layer, and presentation layer).

Answer 3

My first question is: Why a web service in the middle? If this is all going to run on the same physical machine, then you may want to refactor a middle tier that is used through a set of interfaces and using direct method calls.

I am working on an architecture that is seperated with a middle-tier web service, but it contains all the company critical business logic, and will not be directly exposed to the internet. Something like:

{internet} -> |DMZ| -> Web server -> |Firewalled LAN| -> App server -> Database server

In that case, I do think it adds a layer of security, as the mission critical stuff isn't on the DMZ. Granted it still technically violates some security issues because the web server can contact the app server, but having the app server exposed through a single port to a specific IP in the DMZ is better than having it exposed to the internet.

If you are going to use WCF to communicate between the servers, I would suggest using something like binary serialization over TCP, instead of SOAP. That should perform better (feel free to set up a quick test). I haven't tried it myself, but WCF might be able to serialize a dataset or table over the wire. See here.