N-tiers architecture with dot net technologies

Question

I have seen n-tiers solutions on the web, they all use DLLs for each layer. Our architecture looks the same : 3 DLLs : Data layer, a Business Logic layer and a Business objects Layer. However, the presentation layer does not directly communcaite with these layers but instead access them through a WCF web service.

Our ASP.NET MVC is hosted on the same machine as the WCF WebService.

Is that a good architecure? would it be more logical if the ASP.NET MVC had drect access the other layers?

Thank your for your eventual answers.

Answer 1

Your architecture should be dictated by your audience. If you have a very large audience (measured in requests per period), then you'll likely want a distributed architecture that utilizes web services in a manner similar to the one you've described. However, if your audience is small then the approach you've described is VERY overkill.

There is an argument however for keeping your current architecture if you need to update the underlying DLLs but don't want to redeploy your website every time. In your current setup, you'd just be redeploying the web service each time, while the website would remain unaffected. Again, however, unless you have a very active website it probably doesn't matter if you redeploy the website when your DLLs change.

Answer 2

The correct number of dividing lines for tiers is going to depend a lot on things like how tightly the website follows the data model and how much of the heavy lifting is going to end up being done on the database. So it is difficult to answer.

A lot of people spend a lot of time worrying if they have enough/too many tiers and unfortunately a lot of other people spend a lot of time trying to work around tiers dictated to them by others.

To really answer this question you need to think about some things

• The scale of your app now (do you have 5 users or 50,000 users)
• the scaling of your app (how likely would you get to 5,000,000 users before you could upgrade)
• the frequency at which you might completely gut an entire section of the app without re-writing (ie - we have completely changed the business rules, but by some miracle the UI will still be correct as long as you can do the opposite stuff behind this interface)
• the frequency at which you would realistically completely change your storage or database infrastructure (as a .net developer I haven't been at many shops that have just woken up one day and decided to switch DMBS, but I have had a lot of managers insist on abstraction tiers "just in case" that cost tens of thousands on man-hours over time rather than use linq2sql or EF)
• does one of your tiers include something inherently painful that really should be out-of-band to the web ui resources (processing images or office documents are two good examples of something to move to a service just to isolate the overhead/instability sometimes)

I am not trying to imply that these things never happen, they certainly do, but for a lot of devs in a lot of business lines they just don't happen as much as the theory would lead you to believe.

A lot of this stuff just comes down to don't make a tier out of something you cannot realistically see replacing without rewriting other parts of your app. The rest comes down to trying to guess where you cross the line from well designed to premature optimization.

IMHO - For the serialization and encoding penalties alone I would never write a UI over a web app if they were ALWAYS going to run on the same server. If you are doing this initially with the theoretical need of scaling the service elsewhere later I can understand the motivation but there are some other issues like cached data expiration and transactions that often come up to make this still an awkward choice if everything really has to run through a WCF service. It triples the number of things that you have to change to add a field and cuts you off from a lot of the features of using a relational database.

edit

OP made a comment that WCF service is behind several frontends so the Service is not always on the same host as the UI effectively. You still have the option of using the MVC to return rest endpoints and keeping the main web UI fully attached to the backed if you were to add data options to your mvc app to return JsonResults or something