At Onyxtek we believe in the strict separation of layers. We have typically used the MVVM pattern when designing our projects. Over the next few posts I am going to learn Microsoft MVC and compare it to my experiences with MVVM.
A brief lesson on MVVM. MVVM stands for Model-View-ViewModel
What this means is the UI presentation, the View, is completely seperate from the data and business layers, the Model, and they are tied together through the ViewModel.
The View and the Model only communicate through the ViewModel.
Our typical projects are laid out like this:
I was recently asked why we typically make our business layer a web service. The short answer is to make it easier to reuse it outside of ASP.Net. The business layer can be used in a WinForm app, a phone app, or in other related websites. It allows us to give access to our API to whatever and whomever we choose.
The View
Our views are pretty simple. They are standard ASPX files with very little in the code behind, though more than what would be in MVC or other implementations of MVVM.
Our login page looks like this
protected void Page_Load(object sender, EventArgs e)
{
if (Request.Url.AbsoluteUri.ToLower().Contains("logout"))
{
Response.Cookies["login"]["username"] = "";
Response.Cookies["login"]["sessionGuid"] = "";
Response.Redirect("/Member/Login");
}
string email = (Request.Cookies["login"] ==null) ? "" : Request.Cookies["login"]["username"];
string sessionGuid = (Request.Cookies["login"] == null) ? "" : Request.Cookies["login"]["sessionGuid"];
Business.Entities.Member member = new Business.Entities.Member
{
Email = email
};
member = Helpers.AuthenticationServiceHelper.LoginMember(member, sessionGuid);
if (member != null)
{
this.MasterPage.Member = member;
Response.Redirect(this.Redirect);
}
}
There is just some basic code to check if it is a logout and checks the cookies to see if the user has saved their login. In a typical MVVM pattern, there would be a ViewModel called Login and this code would be moved into there. The reason we don’t do this is because there is extra code to make this wire up correctly in ASP.Net. In Silverlight the extra code is not needed, so for Silverlight projects we use actual ViewModels.
The ViewModel
The way we treat ViewModels for ASPX is basically just a helper class. The helper calls the webservice, and handles any cleanup
public static Business.Entities.Member LoginMember(Business.Entities.Member Member)
{
return AuthenticationServiceClient.LoginMember(Member);
}
The Model
Our model is spread between the Data and Business Layers. It is generally a bad idea to use the generated classes from Entity Framework as your entity classes.
[Serializable]
public class Member : Login
{
public AccountType AccountType { get; set; }
public string Company { get; set; }
public Address Address { get; set; }
public string Phone { get; set; }
public IList<Restaurant> Restaurants { get; set; }
public CreditCard CreditCard { get; set; }
}
}
This is our Member Class. For the most part it is a copy of our EF generated class. Member inherits from Login which handles all the login functionality. Items like hashing of the password are all handled from the Login class.
This class is loaded by a “Management” class
public Business.Entities.Member LoginMember(Business.Entities.Member Member)
{
Business.Entities.Member returnValue = (from m in DBContext.Members
where
m.Login.Email == Member.Email && m.Login.PasswordHash == Member.PasswordHash
select new Business.Entities.Member
{
ID = m.MemberID,
AccountType = new Business.Entities.AccountType
{
ID = m.AccountType.AccountTypeID,
CostPerTransaction = m.AccountType.CostPerTransaction,
HasDomainMapping = m.AccountType.HasDomainMapping,
...
I know to some people this may seem like overkill, but I have found, through failures and successes, that having this separation is the best way, so far. I say so far because we are constantly learning and growing.
How do you feel about this method? How would you add or change how we do things?
In my next post, I will start learning Microsoft MVC, and I will see how it compares to how we do things.
