Welchen Leistungseinfluss hat das Schreiben von C# -Code in Sichten, die auch in Controller/Business geschrieben werden können?

Question

Ich habe dies getan, um zusätzliche View Model Mappings in der Business-Klasse zu vermeiden. Beispiel:

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; 
    } 
} 

Verschobene den kommentierten Code in dem oben genannten Geschäft auf Ansicht, Schleifen und in HTML angezeigt wird. Auf diese Weise besteht keine Notwendigkeit für patientInfoVM View Model. Aber ich überspringe die Business-Schicht insgesamt und binde die Entity von Service-Layer direkt in Sicht!

Answer 1

Ohne harte Metriken kann ich nur meine Meinung abgeben, aber anstelle von anderen, analytischeren Antworten, hier ist es.

Ich würde sagen ja, setzen Sie Ihre Geschäftslogik in einer separaten Schicht wird etwas mehr Overhead und daher schlechter Leistung. Andererseits würde ich auch sagen, dass ich mehr Leistung bringen könnte, wenn ich im rohen Maschinencode schreiben würde, aber das wäre verrückt. So, hier sind meine Gründe, warum die etwas schlechter Leistung wert ist:

• Wartung von Datenzugriffscode in Ihren Ansichten gemischt wird zu einem Alptraum werden - Sie werden am Ende neu zu schreiben den gleichen Zugang Standardcode um ein Vielfaches (da Sie die Abfragelogik in anderen Ansichten nicht wiederverwenden können)
• Ansichten werden normalerweise JIT-kompiliert (es sei denn, Sie schalten diese aus), und oft kommt das Intellisense nicht ganz auf, was Sie tun, so können Sie Kompilierzeit Bugs bis zur Laufzeit
• Leck Debugging durch Ansichten saugt - es tut nur
• Mischen von Ihrem Präsentationscode und Ihre Geschäftslogik ist in der Regel eine "schlechte Idee" - vor allem, weil die beiden Anliegen viel zu vermischen werden
• Sie verwenden eine List<> in Ihrem Beispiel, die eine leistungsschwächere Convenience-Struktur ist: so ist es OK dafür, warum nicht für MVC?
• Wie gehen Sie Fehler in Ihrer Sicht? Erfassen Sie Ausnahmen und geben Sie unterschiedliche Markierungen aus?Wie übersetzt sich das in Anzeigevorlagen, Teilansichten und andere solche Dinge?

Wie auch immer, das ist alles meine Meinung: fragen Sie sich, warum Sie diesen Rahmen verwenden, und was das letzte Quäntchen Leistung könnte man auf andere Weise kosten. Aber die Entscheidung liegt bei Ihnen.

Answer 2

Ich glaube nicht, dass die Wartbarkeit vs Performance sollte nicht die Frage hier sein. Alles dreht sich um Zeit. Je weniger Zeit Sie zum Entwickeln/Lesen/Ändern Ihrer Lösung benötigen, desto besser. Daher müssen Sie Ihre Lösung in Schichten aufteilen. Wenn sich etwas in der Datenebene ändert, sollten Sie Ihre GUI-Ebene nicht ändern müssen. Voroptimierungen sollten nicht durchgeführt werden. Aber es gibt ein paar Tricks, um Ihren Code effizienter zu schreiben.

Sie könnten eine IEnumerable<patientInfoVM> zurückgeben. Dies wird die patientInfoVM faul erstellen. Dadurch wird das Element nur beim Iterieren erstellt.

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 
     }); 
    } 
} 

---

Wenn Sie das Ergebnis nur diejenigen durchlaufen, können Sie es wie folgt verwenden:

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

---

Aber wenn Sie brauchen, um die Ergebnisse mehr als diejenigen verwenden, können Sie sollte bestehen die Einzelteile:

var patientInfoList = GetPatientInfo().ToArray(); 

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

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