Производительность CSLA.NET Framework

Question

Наша система использует слой данных на основе Entity Framework. В последние месяцы мы использовали объекты, созданные EF, для передачи данных, бизнес-логики и пользовательского интерфейса.

Поскольку наше приложение становится все больше и больше, мы приняли решение создать отдельный бизнес-уровень, и мы использовали CSLA.NET Framework, чтобы помочь нам в этом. Это должно было помочь нам "масштабироваться" по мере увеличения нагрузки на нашу систему.

Мы находимся в середине разработки нового BL, и я сравнивал производительность модулей приложения до и после их миграции на использование нового BL. Я заметил почти в 50 раз более медленную производительность! Это не 50%, это в 50 раз медленнее.

Я знаю, что введение BL добавит некоторую задержку из-за дополнительного слоя и так далее, но я не ожидал, что задержка будет такой величины.

Это нормально? Существуют ли какие-либо критерии для проведения грани между приемлемой введенной задержкой (из-за добавленного уровня) и между "мы потеряли больше, чем могли бы получить"

Благодарю.

Answer 1

Я не ожидал, что все будет так медленно, но по опыту... моя группа начала использовать CSLA (v4) в прошлом году, и одно из первых наших приложений стало чрезвычайно медленным при загрузке больших списков данных. Хранимая процедура для списка возвращалась менее чем за секунду, но методы бизнес-объекта Data Portal заняли более 10 секунд. В нашем конкретном случае проблема закончилась тем, что мы создавали экземпляр класса поставщика событий WCF, когда каждая запись загружалась в объект списка. Как только мы поняли и решили эту проблему, производительность стала очень быстрой.

Итак, я бы не ожидал, что использование CSLA станет причиной задержки, как вы упомянули, но неправильное использование (например, то, что я делал) может легко вызвать проблемы.