Производительность 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 станет причиной отставания, как вы упомянули, но использование его неправильным способом (например, то, что я делаю) может легко вызвать проблемы.