Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m working on a relatively small asp.net web application and am wondering if there is really a need to employ full n-tier architecture. For an idea of size; there are about 20 database tables.
In the past I have used a 2-tier approach where business logic and data access are grouped together into a single class library with was an asp.net web application forming the UI tier and this seemed to work OK.
Is there a threshold size or some rule of thumb where you should employ n-tier?
It may be relatively small now but do you think it might grow in the future? Of your course you have to be pragmatic, but if you already have natural separations of concern within your single assembly then it’s fairly easy to split that into two or more assemblies. If the classes themselves combine business logic and data access then you have more work on your hands. However, I’d argue that it’s almost no more work to write your data access logic in one assembly and your business logic in the other, in parallel if required, than to write it all in one place in the first place.