【发布时间】:2014-03-17 09:08:21
【问题描述】:
根据this 的介绍(更多细节),过度的层和组装似乎会导致性能问题。看看这个场景,它是关于在应用程序的“联系我们”部分发送消息:
[HttpPost]
public ActionResult Create(ContactViewModel contactViewModel)
{
var request = new CreateContactRequest(contactViewModel);
_contactService.CreateContact(request);
return View();
}
通过请求响应模式创建联系人只是一个 MVC 控制器操作,现在关于服务层中的服务方法 imp 我有这段代码:
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 模式提交后,它会持续存在于数据库中。我确实减少了代码量以及在数据库中创建这个简单联系人的所有过程。此代码实现已在域驱动设计及其模式中完成。显然,它对于每次更改都更具可读性、可维护性和可扩展性,但我也可以编写类似的内容来创建联系人:
[HttpPost]
public ActionResult Create(Contact contact)
{
SessionFactory.GetCurrentSession().Save(contact);
return View();
}
在这种实现中,没有必要去扔五层来保持联系,是吗!? 我知道对于创建联系人和这种简单的业务,第二个小鬼是最好的,但对于复杂的业务,不可能有一个行动来处理所有事情。绝对是由 B 调用 A 和由 C 调用 B 和 ... 会产生一种性能问题。
现在我只想知道优化分层架构性能的方法是什么?
【问题讨论】:
-
调用方法永远不会导致性能问题。如果您
do遇到性能问题,您需要确定瓶颈究竟发生在哪里。如果你不这样做,那就忘记这一切。过早的优化是万恶之源。 -
那你就可以看上面我喜欢的演示文稿看样片了。
-
@HighCore 这不是真的。如果调用方法没有成本,就没有理由内联调用。我不能说调用是否是问题中的问题,但是您声称“调用方法永远不会导致性能问题”的说法根本不正确。
-
确保第二种方法 imp 在一个程序集中,并且绝对比拥有大量不同程序集更快。你可以测试一下
-
forums.asp.net/t/1591736.aspx 和wiki.answers.com/Q/… 中有很好的讨论,但不是我问题的最佳答案
标签: c# performance architecture