0
基於this演示文稿（更多詳細信息），看起來有不適當的圖層和裝配會導致性能問題。看看這種情況下，它是關於應用程序的「聯繫我們」欄目發送消息：更多圖層和性能問題
[HttpPost]
public ActionResult Create(ContactViewModel contactViewModel)
{
var request = new CreateContactRequest(contactViewModel);
_contactService.CreateContact(request);
return View();
}
它僅僅是一個MVC控制器動作，以創建由請求響應模式的接觸，現在關於服務的方法小鬼在服務層我有這一段代碼：
public CreateContactResponse CreateContact(CreateContactRequest request)
{
var response = new CreateContactResponse();
var contact = request.ContactViewModel.ConvertToContactModel();
try
{
_contactRepository.Add(contact);
_unitOfWork.Commit();
response.Success = true;
response.MessageType = MessageType.Success;
response.Message = ServiceMessages.GeneralServiceSuccessMessageOnCreation;
_logger.Log(response.Message);
}
catch (Exception exception)
{
response.Success = false;
response.MessageType = MessageType.UnSuccess;
response.Message = ServiceMessages.GeneralServiceErrorMessageOnCreation;
_logger.Error(exception.Message);
}
return response;
}
服務方法轉換視圖模型由一個擴展方法來建模和它調用的nHibernate的以下方法中數據的基礎上，以堅持庫層：
public void Add(T entity)
{
SessionFactory.GetCurrentSession().Save(entity);
}
並最終在通過UnitOfWork模式提交後，它仍然存在於數據庫中。我真的減少了代碼量以及在數據庫中創建這個簡單聯繫人的所有過程。這個代碼實現已經在Domain Driven Design和它的模式中完成了。這顯然是更具可讀性和可維護性和可擴展的每一個變化，但我也可以寫像這樣創建聯繫人：
[HttpPost]
public ActionResult Create(Contact contact)
{
SessionFactory.GetCurrentSession().Save(contact);
return View();
}
在這種實現的，也沒有必要去扔五層堅持一個聯繫人，是的！？ 我知道創建一個聯繫人和這種簡單的業務第二imp是最好的，但對於複雜的企業，它不可能有一個行動來處理一切。絕對由C和B調用A和B是...造成一種性能問題。
現在我只想知道優化分層架構性能的方法是什麼？
調用方法永遠不能導致性能問題。如果您確實遇到性能問題，您需要確定瓶頸發生的位置。如果你不這樣做，那就忘記了。不成熟的優化是萬惡之源。 –
然後你可以看到我喜歡的演示文稿，以查看示例。 – Ehsan
@HighCore這是不正確的。如果調用方法沒有花費，則沒有理由內聯調用。我不能說這個調用是否是問題中的問題，但是您聲稱「調用方法永遠不會導致性能問題」是不正確的。 –