What is the performance impact of writing C# code in views which can also be written in controller/ business?

Question

I have done so to avoid extra View Model mappings in Business class. Example:

public class PatientInfoBusiness
{
    public List<PatientInfo> GetPatientInfo()
    {
        IPatientInfoService proxy = new VRFactory().GetPatientInfoServiceProxy();
        var piData= proxy.GetPatientInfoSectionData();

        //var patientInfoVM= new List<patientInfoVM>();
        //piData.ForEach( a => patientInfoVM.Add(
        //                                                          new patientInfoVM
        //                                                          {
        //                                                              AcknowledgedUserName = a.AcknowledgedUserName,
        //                                                              Description = a.Description,
        //                                                              PriorityCode = a.PriorityCode,
        //                                                              Status = a.Status
        //                                                          }
        //                                        )
        //                );

        return piData;
    }
}

Shifted the commented code in the above Business to View, looping through and displaying in HTML. This way no need of patientInfoVM View Model. But I am skipping the business layer altogether and binding the entity from service layer directly in view!

Answer 1

Without any hard metrics I can only offer my opinion, but in lieu of other, more analytics-driven responses, here it is.

I would say yes, putting your business logic in a separate layer will cause slightly more overhead and therefore worse performance. Then again I would also say that I could squeeze more performance if I wrote in raw machine code, but that would be crazy. So here are my reasons why the slightly worse performance is worth it:

• maintenance of data-access code mixed in throughout your views will become a nightmare - you will end up re-writing the same access boilerplate code many times over (as you can't reuse the query logic in other views)
• views are typically JIT-compiled (unless you switch that off), and often the intellisense doesn't fully catch up with what you are doing, so you can leak compile-time bugs through to runtime
• debugging through views sucks - it just does
• mixing of your presentation code and your business logic is generally a "bad idea" - mainly because the two concerns become far too intermingled
• you are using a List<> in your example, which is a lower-performance convenience structure: so it's OK for that, why not for MVC?
• how do you error-handle in your view? Are you catching exceptions and outputting different markup? How does that translate into display templates, partial views and other such things?

Anyway, that's all my opinion: just ask yourself why you are using this framework, and what that last drop of performance might cost you in other ways. But the decision is up to you.

Answer 2

I don't think the Maintainability vs Performance shouldn't be the question here. It's all about time. The less time you need to develop/read/modify your solution, the better. Therefore you need to split your solution in layers. If something changes in the data-layer, you shouldn't have to modify your gui-layer. Pre-optimalizations should not be done. But there are a few tricks to write your code more efficient.

You might return an IEnumerable<patientInfoVM>. This will create the patientInfoVM lazy. This will only create the item when iterated.

public class PatientInfoBusiness
{
    public IEnumerable<PatientInfo> GetPatientInfo()
    {
        IPatientInfoService proxy = new VRFactory().GetPatientInfoServiceProxy();
        var piData= proxy.GetPatientInfoSectionData();

        return piData.Select(a => new patientInfoVM
        {
          AcknowledgedUserName = a.AcknowledgedUserName,
          Description = a.Description,
          PriorityCode = a.PriorityCode,
          Status = a.Status
        });
    }
}

---

If you iterate the result only ones, you can just use it like this:

foreach(var patientInfo in GetPatientInfo())
{
    // do something.
}

---

But if you need to use the results more than ones, you should persist the items:

var patientInfoList = GetPatientInfo().ToArray();

foreach(var patientInfo in patientInfoList)
{
    // do something.
}

foreach(var patientInfo in patientInfoList)
{
    // do something.
}