Converting ASP.NET MVC to n-Tiered Architecture

I just built an application using ASP.NET MVC. The programmers at my company want to build all future modules using n-Tiered (Presentation Layer, Business Logic Layer, Data Access Layer) architecture.

I am not the programmer and need to know wh开发者_JAVA百科y this makes sense? Do I have to completely rewrite the entire code or can it be converted?

We are building an HRIS system with Business Intelligence.

Somebody please explain why or why not this approach does or does not make sense.

Honestly, it doesn't make sense to me.

In "N-Tier" architecture, you have three layers:

• Data Access Layer
• Business Logic Layer
• Presentation Layer

In MVC (short for Model, View, Controller), you have three layers:

• Model (Data Access Layer) (if you use the Repository pattern)
• View (Presentation Layer)
• Controller (Business Logic Layer)

In short, your application is already written, and provides separation of concerns. Now they want to rewrite it to essentially just rename folders?

That doesn't make sense at all.

Without knowing more detail about your problem there are a few issues that can be discussed:

Three tier architectures are a good idea because they tend to easily separate the concerns of the classes that make them up into more flexible and easy-to-understand categories:

1) data/persistence 2) business logic 3) presentation/GUI

Following this basic pattern does make sense with any software project where data collection and retrieval (vast majority of biz apps) is involved. There are dozens of other reasons as well and too numerous to list here.

Now, being able to arrive at the three tier architecture by refactoring an existing base of code depends greatly on how that code was developed. And that brings up the age-old software development question of: do we refactor or start from scratch? It all depends on the code... and the people writing the "new" code.

i would suggest that if your programmers have a good knowledge of the domain and of what they are trying to accomplish (or a stellar technical spec) then a rewrite could be useful even if refactoring seems like a possibility. Conversely, if those same programmers do not have expert knowledge in the problem domain or there's no spec then perhaps it would be worth while to try and refactor the existing logic into the three tiers and thereby preserving the biz logic that was originally established.

In short, many a book have been written on the dilemma you face. But there are two programming rules of thumb that i covered here and that will show up in any software development manual:

• structure is good e.g. three tier architecture, MVC, patterns
• refactoring is good - leads to cleaner, more maintainable, performant, understandable code

Good luck!

Tiers are more related to the physical architecture than the logical? see Multi-tier architecture

If you have seperated M, V and C from each other in your current application you already have a good logical architecture.

If the developers think some of the concerns are not separated properly, I would ask them to refactor the existing code into smaller chunks (shorter methods and classes with single responsibilty) and move these into relevant tiers/assemblies/namespaces whatever you see fit, -for example- data access code into data access layer if your MVC application has indeed a persistency which is not a requirement for MVC.

The 3-tier approach indeed does promote better reusability down the road. In fact, your recently built MVC based app could utilize the 3-tier model (the model and controller parts at least). The MVC controller can act as the facade utilizing the 3-tier solution in the backround.