N-Tier Architecture RRS feed

  • Question

  • User-353733005 posted

    I want to know tier architecture format. How or where I learn that? Can anyone help me please.

    Thank you in advance. :)

    Monday, August 18, 2014 11:10 AM


All replies

  • User-484054684 posted

    As you might know, it is general concept irrespective of .net.

    Tiering is more of a deployment strategy which enables you to deploy your components into multiple physical locations.

    More details about this discussion can be found here:

    If you are specific about ASP.NET webforms:

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, August 18, 2014 11:21 AM
  • User774448340 posted


    Take a look at the following solution: http://1drv.ms/1snusT3. It doesn't have an ASP.NET webforms front-end but uses MVC instead. Also DI is included.

    Hope this helps.



    Monday, August 18, 2014 11:50 AM
  • User-353733005 posted

    Thanks :)

    Monday, August 18, 2014 11:53 AM
  • User-1611549905 posted

    Just a word of caution here. While the traditional layered architecture can be a good starting point for your application, it's surrounded by a minefield of cargo cult programming and so-called "best practices" that are dubious at best and outright harmful at worst.

    Here are some dos and don'ts to look out for when implementing a layered architecture:

    • Don't waste time and effort trying to make your data access layer interchangeable to swap out NHibernate for Entity Framework or RavenDB. This one's nothing short of stealing from your client. You're being paid to deliver business value, not to faff about with cumbersome hypotheticals that you're not being asked for, you're almost certainly not going to need, and usually don't even work in the end.
    • Similarly, don't plan for moving your UI layer to a separate tier. Fowler's Law of Distribution applies here: don't. Keep it all on one physical server. If you need to scale out, there are other more effective ways of doing it, such as load balancing, caching, sharding, scheduled tasks, denormalisation, or CQRS/Event Sourcing.
    • Don't be afraid to write tests that hit the database. Some people say you shouldn't do this: they're wrong. Your DAL is both the most error-prone and the most business critical part of your application, as well as being pretty complex. It needs more tests, not fewer.
    • Do ignore the rule that says that each layer is only allowed to talk to the one immediately below it. If your business layer contains classes or methods that do nothing other than shuffle data from one set of classes to another set of identical classes, you should bypass it altogether and go straight from your presentation layer to your ORM.
    • Don't wrap your ORM in a Repository initially. You can always add a Repository layer later on if it turns out to be necessary. If you do, only use it for those parts of your code that need it. Don't make it mandatory for everything.
    • Don't put the different layers of your code in separate assemblies. This just adds friction and complexity without giving any benefits whatsoever. The only reason people do it is because they're striving for some kind of architectural purity where each layer is only allowed to talk to the one directly below it. As I've already noted, you shouldn't be restricting yourself in that way anyway.
    • Don't fall into the trap of thinking that a certain approach is more professional or better suited to business critical code just because it's more complex. Every complexity that you introduce needs to have a business justification and you need to know what that justification is. Introducing complexity for which there is no business justification is not professional, it's stealing, and introducing complexity that you don't properly understand is just reckless.
    • Do study alternatives to the traditional layered architecture. For example, you could consider query objects as an alternative to a Repository, or introducing various concepts from CQRS and Event Sourcing. Be careful with the latter though: far too many projects go completely overboard with the whole CQRS/ES thing and give it a bad name when all that's needed are some of the simpler concepts, such as having separate models for reads and writes.
    • Do experiment with different approaches and architectures on a hobby project or two before you try introducing them into business-critical code.
    • Do bear in mind that different parts of your project may be better suited to different architectures. Don't aim for a "one size fits all" approach.
    • Do review your approach regularly at your sprint retrospectives.

    I realise that some of the advice I'm giving here may make purists howl, but remember that your clients expect you to be a pragmatist, not a purist. Keep it simple, ruthlessly eliminate unnecessary complexity to begin with, and only add it back in if it's strictly necessary.

    Monday, August 18, 2014 7:22 PM
  • User-821857111 posted

    I realise that some of the advice I'm giving here may make purists howl

    Let them howl, I say.

    Tuesday, August 19, 2014 8:55 AM