My first steps moving away from just putting everything in each web page were rough. So, now I am trying to create an organized N-Tier web app. There is lots of discussion of this all over the web, and each person seems to set things up a little differently, depending on what problem they are trying to solve. After some exhaustive research, I have decided to go down this path, and I hope that this basic structure will work for future apps without two much trouble.
Data Tier: SQL Server 2005 – I didn’t have any choice here. This is what my company uses. They are planning on switching to 2008 soon.
Data Access Tier: Entity Framework 5 – At this point I am gonna stick with Microsoft as much as possible. I am using the DbContext API. I have bounded contexts, with each context being a separate Visual Studio project. I have an additional ‘Migrations Context’ for Code First Migrations. Oh yes, I am using Code First.
Repository Tier – This is where my Linq will reside. I am using Dynamic Linq in a few locations, to allow the user to design some queries for themselves. Also a separate Visual Studio project.
Business Tier – This is the actual business logic of the application. This layer is entirely Entity Framework independent. Also a separate Visual Studio project.
User Interface Tier – These are the .aspx pages.
Entities – These are the POCOs that hold that hold the actual data. You guessed it… a separate Visual Studio project.
Each tier can only access the tier immediately above of below it, except the entities, which are available to any tier. Future posts will discuss how I structured each tier.
Data Access Tier is based on ideas suggested by Julie Lerman: http://msdn.microsoft.com/en-us/magazine/jj883952.aspx
I went with the repository pattern because of this: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application