Home/ Questions/Q 7669869
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T15:41:34+00:00

I am developing a web based application whose primary objective is to fetch data

  • 0

I am developing a web based application whose primary objective is to fetch data from the database, display it on the UI, take in user inputs and write them back to the database. The application is not going to be doing any industrial strength algorithm crunching, but will be receiving a very high number of hits at peak times(described below) which will be changing thru the day…

The layers are your typical Presentation, Business, Data. The data layer is taken care of by the database server. The business layer will contain the DAL component to access the database server over tcp. The choices I have to separate these layers into tiers are:

  1. The presentation and business layers can be either kept on the same
    tier.

  2. The presentation layer on a separate tier by itself and the business
    layer on a separate tier by itself.

In the case of choice 2, the business layer will be accessed by the presentation layer using a WCF service either over http or tcp.

I don’t see any heavy processing being done on the Business layer, so I am leaning towards option 1 above. I also feel for the same reason, adding a new tier will only introduce the network latency. However, in terms of scalability in case I need to scale up or scale out, which is a better way to go? This application will need to be able to support up to 6 million users an hour. There will be a reasonable amount of data in each user session, storing user’s preferences and other details. I will be using page level caching as well..

Thanks for your time…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I really really do not like the term ‘n-tier-architecture’ when talking about simple CRUD web applications. Pick a design pattern like MVC, and go for it. Forget about the tiers altogether.

    Your application isn’t going to be big enough or popular enough to worry about scaling individual components separately. In all likelihood, your application is going to be a single VS solution (and possibly even a single Application within the project). If any of what I’ve said seems a little mean, I apologise, but I count nearly everything I’ve built in the same bucket. Also, if anything I’ve said is totally incorrect in your specific project, I apologise again, and accept the downvotes humbly. It really does sound like you’re over thinking this. Build it and see.

    You’re building a web site with input, display, and data access. Fire up a new ASP.NET MVC solution, and go to town.

    • 0