[This post is based on a document authored by Ben Grover (a senior developer at Microsoft). It is our intention to integrate this information into the MVC 3 documentation on MSDN. We hope to hear from you and welcome any suggestions you might have.] This document presents a set of coding guidelines aimed at helping the ASP.NET MVC developer create solid applications. Of course, it's up to you as the developer to decide which of these guidelines are appropriate for your application. Model Recommendations
The model is where the domain-specific objects are defined. These definitions should include business logic (how objects behave and relate), validation logic (what is a valid value for a given object), data logic (how data objects are persisted) and session logic (tracking user state for the application). DO separate the model its own project with a distinct assembly.
For applications with a large complex model, it's a good idea to create a separate assembly for the model to avoid accidently mixing concerns. You can then reference the model assembly in your ASP.NET MVC project. DO put all business login in the model.
If you put all business logic in the model, you shield the view and controller from making business decisions concerning data. You also reap the following benefits:Less duplicated business logic.
The view is easier to read when there is no business logic present.
Testing business rules is isolated to the model.
For example, if you have a business requirement to display a user's name with the last name first, you could put the logic in the view as follows: <% if (String.Compare((string)TempData["displayLastNameFirst"], "on") == 0)
{ %>
Welcome, <%= Model.lastName%>, <%= Model.firstName%>
<% }
else
{ %>
Welcome, <%= Model.firstName%> <%= Model.lastName%>
<% } %>However, you would have to duplicate this logic in every place this business requirement was needed. Read more: ASP.NET and Web Tools Developer Content Team
The model is where the domain-specific objects are defined. These definitions should include business logic (how objects behave and relate), validation logic (what is a valid value for a given object), data logic (how data objects are persisted) and session logic (tracking user state for the application). DO separate the model its own project with a distinct assembly.
For applications with a large complex model, it's a good idea to create a separate assembly for the model to avoid accidently mixing concerns. You can then reference the model assembly in your ASP.NET MVC project. DO put all business login in the model.
If you put all business logic in the model, you shield the view and controller from making business decisions concerning data. You also reap the following benefits:Less duplicated business logic.
The view is easier to read when there is no business logic present.
Testing business rules is isolated to the model.
For example, if you have a business requirement to display a user's name with the last name first, you could put the logic in the view as follows: <% if (String.Compare((string)TempData["displayLastNameFirst"], "on") == 0)
{ %>
Welcome, <%= Model.lastName%>, <%= Model.firstName%>
<% }
else
{ %>
Welcome, <%= Model.firstName%> <%= Model.lastName%>
<% } %>However, you would have to duplicate this logic in every place this business requirement was needed. Read more: ASP.NET and Web Tools Developer Content Team
Posts
0 comments:
Post a Comment