Question

基于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模式提交后，它仍然存在于数据库中。我真的减少了代码量以及在数据库中创建这个简单联系人的所有过程。这个代码实现已经在Domain Driven Design中完成了它的模式。对于每次更改，它显然更具可读性和可维护性，并且可以扩展，但我也可以编写类似的内容来创建联系人：

[HttpPost]
public ActionResult Create(Contact contact)
{
    SessionFactory.GetCurrentSession().Save(contact);
    return View();
}

在这种实现中，没有必要再扔五层来坚持联系，是的！？我知道创建一个联系人和这种简单的业务，第二个影响是最好的，但对于复杂的企业来说，无法采取行动来处理所有事情。肯定用B和B用C和A来调用A是一种性能问题。

现在我只是想知道优化分层架构性能的方法是什么？

Answer 1

我在博客上写了一篇关于它的帖子，虽然优化n层架构并不容易，但我已经谈到了一些提示： http://ehsanghanbari.com/Post/115/disadvantages-of-n-layered-architectures

更多层和性能问题

1 个答案: