The problem isn't the if. Sometimes you have to present things differently based on some aspect of the model. The "problem" is the Salary > 20000 "logic". While the example you've given is probably simple enough that it's not terribly important, ideally that kind of thing doesn't really belong in the view.
The standard way to do this is to make use of a ViewModel. This object exists to decouple the view from the implementation details of your data model, and to encapsulate some presentation-layer logic. This is particularly important if your data model is e.g. an Entity Framework proxy which has a lot of constraints and behaviour that force it into the wrong "shape" for your presentation layer. In this particular instance, your ViewModel could have a property along the lines of bool ShowHighSalarySection - either calculated by the ViewModel, or by some external business code and stored in the ViewModel.
The precise shape of your ViewModel will depend greatly on what particular flavour of MV* you follow, but for example:-
- Simple
ViewModel with data-model constructor:-
public class EmployeeViewModel
{
private readonly Employee model;
public EmployeeViewModel(Employee model)
{
this.model = model;
}
public bool ShowHighSalarySection { get { return this.model.Salary > 20000; } }
// Some people like to have the ViewModel explicitly only expose
// the data the view needs.
public string EmployeeName { get { return this.model.EmployeeName; } }
public string Address { get { return this.model.Address; } }
public DateTime DateOfBirth { get { return this.model.DateOfBirth } }
public int Salary { get { return this.model.Salary; } }
// Or, if boilerplate freaks you out, and you don't have the tools
// to automate it, you can even just expose the data model and its
// properties directly as e.g. Model.Employee.EmployeeName.
// This gives you some abstraction very cheaply, but obviously
// still leaves your views somewhat coupled to your data model:-
public Employee Employee { get { return this.Model; } }
}
And then in your view:-
if (Model.ShowHighSalarySection) { ...
- You can also use a more "dumb"
ViewModel along with a mapper such as AutoMapper:-
public class EmployeeViewModel
{
// Note that this ViewModel doesn't even know the data model *exists*!
public string EmployeeName { get; set; }
public string Address { get; set; }
public DateTime DateOfBirth { get; set; }
public int Salary { get; set; }
public bool ShowHighSalarySection { get; set; }
}
In your controller:-
var query = db.Employees.Select(x => ...);
// Some people like the "magic" of a mapper, especially when
// all you're doing is reasonably "dumb" transformations.
// Some people don't like that there could be somewhat complicated
// things going on behind the curtain.
// The huge advantage of this type of code is that you can usually
// leverage some kind of query projection and have the mapping
// take place on your database, rather than pulling the entire
// entity graph into memory.
var viewModel = this.mapper.Project()
.To<EmployeeViewModel>(query)
.FirstOrDefault();
return View(viewModel);
- Sometimes business rules are complicated enough you might want some explicit handling code explicitly responsible for applying the business rule:-
public class GetEmployeeQueryHandler
{
private readonly IEmployeeStore store;
public GetEmployeeQueryHandler(IEmployeeStore store)
{
this.store = store;
}
public EmployeeViewModel Handle(EmployeeQuery query)
{
var employee = store.Get(EmployeeQuery.Identity);
var viewModel = new EmployeeViewModel()
{
// Could leverage some automatic mapping to do the
// "dumb" part of the mapping if you want tidiness
// or query projection.
}
// This is probably excessive for a calculation as simple
// as this one, but we've managed to separate ourselves
// totally from both the database *and* the rendering
// engine.
// This lets us e.g. test our important business logic in
// complete isolation, or reuse it elsewhere.
viewModel.ShowHighSalarySection = employee.Salary > store.HighSalaryThreshold;
}
}
Exactly what goes where will depend on your architecture, your philosophy, and how much boilerplate (or tooling) you're prepared to accept in return for tidiness. The main thing a ViewModel does is it allows you to get business rules out of the view and into somewhere appropriate (safer, more testable, more reusable, and so on).
