2. Models
• Use a consistent naming convention for your model classes.
• Use a singular word for a model class.
• Ensure that your model has a parameter-less public constructor.
• Make full use of the annotation attribute classes to embed basic validation
and data integrity mechanism in your model classes. Examples are
RequiredAttribute, DataTypeAttribute, StringLengthAttribute, etc.
• Create custom validation attributes for custom validation and ensure that
you implement both server-side and client-side logic.
3. Models (Contd.)
• Make non-required numeric and Boolean properties as nullable.
• Use inheritance to reuse common properties across logically related model
classes. For example, if you have EmployeeModel and ContractorModel
classes then having them inheriting from a common model like
PersonModel makes good sense.
4. Models (Contd.)
• Don’t use complex types for your model properties.
• Don’t create methods in a model class. Models are supposed to be plain
classes with read-write properties.
• Don’t create static properties. If you do need few of then they probably
belong somewhere else or perhaps you may want to create few constants in
that case.
• Never make a reference to a controller class or a view within a model.
Model is not supposed to know anything about a controller or a view’s
existence.
5. Views
• Ensure the folder structure and the names of your views match with your
controllers and controller actions.
• Any block of HTML that is repeated in more than one view should go inside
a layout view or a partial view.
• Use ViewBag object to pass data to layout views.
• The HTML for displaying messages should be placed in a layout view or a
partial view.
• Layout and partial views should be prefixed with _ character.
6. Views (Contd.)
• Don’t import namespaces within a view. Instead make use of the
namespaces tag in the web.config file.
• Never make a reference to a controller class within a view with the
exception of generating action links.
• Never retrieve data from a data source or a business component directly
from a view. That’s the controller job!
7. Controllers
• Always have a Home controller.
• Always have an Index action for every controller.
• Use a consistent naming convention.
• Each controller should be responsible for a single logical domain object.
• Choose a plural word for a controller especially if the Index action of the
controller renders a list of data.
• Try to name controller actions with simple verbs as applicable. Examples are:
New, Edit, and Delete.
8. Controllers (Contd.)
• Use the Authorize attribute at the class level unless the controller by
definition allows anonymous access to all its actions. Applying Authorize
attribute at the class level and then selectively applying AllowAnonymous
attribute on the actions that need it is a good strategy.
• Apply output caching on controller actions that render static HTML or
content that doesn’t have to be real-time. You should apply output caching
at the controller level if applicable.
9. Controllers (Contd.)
• Don’t duplicate utility code in controllers such as displaying messages.
Instead create a common controller class (that inherits from the Controller
class) with common methods and properties.
• Don’t duplicate exception management logic in your controller actions.
Instead use the ExceptionFilterAttribute to handle exceptions.