Introduction
This article is about a possible way to implement an N-Tier architecture for ASP.NET MVC (Model View Controller), using WCF (Windows Communication Foundation = replacement for .NET Remoting) and LINQ to SQL. This article will not go in depth explaining the ins and outs of MVC, WCF, and LINQ (there's already enough stuff which explains these technologies ...); instead, I'll be showing a possible way to implement these features in an N-Tier environment, by means of a simple bug-tracking demo application.
Requirements of the Bug-Tracking Demo Application
First, we should state the requirements of our demo application. These are quit straightforward, as mentioned beneath:
- We want the application to produce a list of currently added bug-tracking tickets.
- We want the possibility that a user can add a ticket to the system, which evolves adding a ticket date, selecting a user to whom we grant the ticket, adding a ticket date, and letting the user add some comments.
- Before adding a new ticket to the system, we want to be sure that the user has supplied a valid date, selected a ticket type and user, and added some comments for the ticket.
Architectural Overview
The .NET Solution consists of three main projects:
- BtDataLayer: Contains the model classes and the data access routines.
- BtWcfService: Contains the services which the presentation layer may call.
- BugTracking: Contains the presentation layer (ASP.NET MVC app).
Another project not mentioned on the diagram above is CommonLib, which contains the commonly used routines (like a business base class which each model class derives from, method for cloning objects, and a business rule validator engine).
Using the Code
The Data Access Layer (BtDataLayer)
- The model classes (BugTracker.dbml):
These are the LINQ-TO-SQL classes retrieved from the SQL-Server Bugtracker database (database template included in the Zip file). As this model should be remotable, the serialization mode on the datacontext should be set to Unidirectional.
- The Data Access Code (btDataManger.cs):
We want to be able to load a user-list so we can select a user for whom the ticket applies to:
public static List<user> GetUserList()
{
BugTrackerDataContext db = new BugTrackerDataContext();
return db.Users.ToList<user>();
}
We want to be able to load a tickettype
list, so we can select the type of ticket (BUG, INFO, etc ...) for the ticket:
public static List<tickettype> GetTicketTypeList()
{
BugTrackerDataContext db = new BugTrackerDataContext();
return db.TicketTypes.ToList<tickettype>();
}
We want to be able to retrieve all the current tickets from our ticket table:
public static IEnumerable<ticket> GetTickets()
{
BugTrackerDataContext db = new BugTrackerDataContext();
return db.Tickets;
}
Finally, we want to have the possibility to persist a newly added ticket (one at a time for the demo application, but we make the method all-purpose, so it can accept many added or modified objects):
public static bool PersistTickets(ref TicketList p_tickets)
{
if (p_tickets == null || p_tickets.Count == 0)
return false;
BugTrackerDataContext db = new BugTrackerDataContext();
foreach (Ticket t in p_tickets)
{
if (t.TicketId == 0)
{
db.Tickets.InsertOnSubmit(t);
}
else
{
db.Tickets.Attach(t, t.IsDirty);
}
}
try
{
db.SubmitChanges(ConflictMode.ContinueOnConflict);
foreach (Ticket t in p_tickets)
{
t.IsDirty = false;
}
}
catch (ChangeConflictException ex)
{
throw ex;
}
return true;
}
The Service Layer
The purpose of our WCF enabled service layer is to make the model and data-access routines (to foresee the model of data ...) available to the presentation layer.
Our service layer consists mainly of two routines:
- The service contract (which contains the routines which can be called by our Web App).
[ServiceContract]
public interface IBtService
{
[OperationContract()]
IEnumerable<user> GetUserList();
[OperationContract()]
IEnumerable<tickettype> GetTicketTypeList();
[OperationContract()]
bool PersistTickets(ref TicketList p_tickets);
[OperationContract()]
IEnumerable<ticket> GetTickets();
}
The Service Implementation, which implements our contract and calls the datalayer.
public IEnumerable<user> GetUserList()
{
return BtDataManager.GetUserList();
}
public IEnumerable<tickettype> GetTicketTypeList()
{
return BtDataManager.GetTicketTypeList();
}
public bool PersistTickets(ref TicketList p_tickets)
{
return BtDataManager.PersistTickets(ref p_tickets);
}
public IEnumerable<ticket> GetTickets()
{
return BtDataManager.GetTickets();
}
The Presentation Layer
The presentation layer contains our ASP MVC application. As already mentioned above, I will not go in depth on MVC, as there is already a lot of info available on the net. But it is important to know that MVC contains three main items, namely the Model (which represents our class, a validation logic, and is remotely available through the Service Layer), the View (our webpage), and the Controller (which basically "hooks" the Model to the View).
The Views and the Controllers
Our demo application hosts the following MVC enabled web pages:
Ticket.aspx
With this page, the user can add a bug-ticket to the system. The HomeController is responsible for rendering the page. While interacting with the page, there are two actions involved, one for creating a new ticket (the "GET") version, and one for persisting a new ticket (when the user hits the Submit button: the POST version).
[AcceptVerbs("GET")]
public ActionResult Ticket()
{
this.LoadSelectionLists();
var userList = new SelectList(_userList, "UserId", "Username");
ViewData["UserId"] = userList;
var ticketTypeList = new SelectList
(_ticketTypeList, "TicketTypeId", "TicketTypeDescription");
ViewData["TicketTypeId"] = ticketTypeList;
return View();
}
When the user selects "Create Ticket" in the index page, we must create a new page where the user may enter the ticket details. As the user should have the possibility to select a user and ticket type for the ticket, these data are loaded from the service and added to the viewstate of the form:
private void LoadSelectionLists()
{
BtServiceRef.BtServiceClient proxy = new
BugTracking.BtServiceRef.BtServiceClient();
_userList = proxy.GetUserList();
_ticketTypeList = proxy.GetTicketTypeList();
}
On the other hand, the post version is executed when the user hits the "Submit" button. We will create a ticket object, map the properties to the field properties of the form, validate the objects data (see the source code of the model for detailed validation information as validation data is stored in the model classes), and persist the newly added ticket through the service to the database.
[AcceptVerbs("POST")]
public ActionResult Ticket(FormCollection p_form)
{
var TicketToCreate = new Ticket();
try
{
this.UpdateModel(TicketToCreate, new[]
{ "UserId", "TicketTypeId", "Comment", "GrantedToDate" });
TicketToCreate.Validate();
added ticket
if (TicketToCreate.HasErrors)
{
foreach(DictionaryEntry entry in
TicketToCreate.ValidationErrors)
{
ViewData.ModelState.AddModelError(entry.Key.ToString
(), entry.Value.ToString());
}
throw new InvalidOperationException();
}
else
{
persist the new ticket.
BtServiceRef.BtServiceClient proxy = new
BugTracking.BtServiceRef.BtServiceClient();
Ticket[] newTicketList = new Ticket[] { TicketToCreate };
proxy.PersistTickets(ref newTicketList);
}
}
catch
{
this.LoadSelectionLists();
var userList = new SelectList(_userList, "UserId", "Username");
ViewData["UserId"] = userList;
var ticketTypeList = new SelectList
(_ticketTypeList, "TicketTypeId", "TicketTypeDescription");
ViewData["TicketTypeId"] = ticketTypeList;
return View(TicketToCreate);
}
return RedirectToAction("Index");
}
There are two comboboxes on the ticket.aspx form: one for user selection and one for ticket type selection. As shown in the code above, we load the user and ticket type records from the service and add them as ViewData of the ticket page. Next, we have to bind the ViewData as mentioned below (you can also notice how we execute the bindings for validation purpose):
Index.aspx
When loading the application in the browser, the index page is the first page shown. We get a list of current tickets in the database and the possibility to add a new ticket to the system:
Again, the HomeController is responsible for rendering the page, the action involved is:
public ActionResult Index()
{
ViewData["Title"] = "Home Page";
ViewData["Message"] = "Welcome to ASP.NET MVC Bugtracker !";
BtServiceRef.BtServiceClient proxy =
new BugTracking.BtServiceRef.BtServiceClient();
return View(proxy.GetTickets());
}
As we will show the current tickets in this page, we first create a reference to our service. This service calls the GetTickets()
method of our data layer data-access class and adds it as input parameter of the view. Next, to be sure that our Index Page is aware of the loaded ticket-list, the BtDataLayer.Ticket
type should be added as an attribute to the derived ViewPage:
Finally, in the HTML code of our index.aspx page, we can loop through our loaded ticket list and place each ticket in a data row:
You may have noticed that I display the UserId
and TickeTypeId
instead of the user name and ticket type description. If you want to view, for example, the username instead of the ID, you should use: t.User.UserName
, but this will return an error, as the user is not loaded with the tickets. You can change this by altering the data access method and adding data load options for the user and ticket type. In this case, the related user and ticket type objects will be loaded too.
Final Word
VoilĂ , that's all to mention. This article showed a possible way to separate logical layers and pass data between boundaries using new technologies such as WCF and LINQ-to-SQL. Finally, it showed a possible presentation layer, using the newest ASP.NET MVC technology. Special thanks goes to the people running the ASP.NET website www.asp.net and also special thanks goes to Beth Massi: http://blogs.msdn.com/bethmassi/, for explaining LINQ-to-SQL and N-Tier through WCF in a well structured and clear view.