Last post Feb 09, 2010 01:21 AM by danludwig
Feb 08, 2010 10:44 PM|sahajMarg|LINK
Most of my earlier applications I have been designing them in a 3 layer architecure, like the following.
1. All Business classes (example Employee) were in App_code folder
2. All Data classes in App_Data folder
3. All HTML code under root directory
But In my new company I saw a totally new approach to seperate layers. They orginzed it into something like the following.
Is the above some standard architecture? If someone can kindly explain. Thanks.
Feb 08, 2010 11:20 PM|danludwig|LINK
Your design doesn't really look like a 3-layer architecture. It just looks like you have everything in one project, but in different folders. Let's say your company decided to put up a mobile web site, or to integrate automated services with their suppliers.
How would you set up the new web services to access your business layer? Your data layer? Copy and paste from App_Code and App_Data to the other project(s)?
The benefit of separating out the software layers into different projects like this is that it promotes reusability. You could have 3 front-end services (a web application, a client app, and a REST service facade for example). All need to abide by the same
business rules, and/or need access to the same sets of data. By having layers separate like this, you can compile each project into a DLL and just add the DLL to the library (bin folder) of the front-end service project.
In the beginning, I usually start with at least 3 projects: a Web Site, a Database project, and a ClassLibrary. The db project is for keeping track of all the SQL files, such as scripts to create/modify tables, triggers, sprocs, etc. We have 3 different
database environments - dev, QA, and production - so I need to keep track of what changes are being made to the db and execute SQL scripts in the other environments as upgrades are promoted.
In the class library, I create an ADO.NET Entity Data Model. This acts as a BusinessObjects layer, and essentially eliminates the need for a data access layer since the Entity Framework takes care of all that. In the web project, I don't put anything in
App_Code that could be reused elsewhere. For example, I might put a custom UserProfile class in there, or a utility class for working with WebControls, but no Business Process code. Instead I keep the business objects and facades in the class library, then
just use that library in the web project.
I'm not sure if the above organization scheme is a standard, but it's darn good practice.
Feb 08, 2010 11:56 PM|sahajMarg|LINK
thx a lot danludwig your reply is making all sense to me. So for a bigger application ther should be atlest 3 projects. Earlier I used to have only one solution file for the entire web site and it did not have any projects.
Also In my company exaple. why do you think they have diff projects for UI and Web? Does that make sense? Also what kind of project can be Domain and BO project?
Feb 09, 2010 01:21 AM|danludwig|LINK
why do you think they have diff projects for UI and Web? Does that make sense? Also what kind of project can be Domain and BO project?
You can have different User Interfaces than just web sites. Windows Forms are a UI. A mobile WML site is a UI. It could even be that they are using a UI project for custom controls that they want to reuse in different web sites / web application projects
(custom controls are UI components).
I think BO is the Business Objects layer. Not sure what the domain project could be, you should ask.