Пытаясь повысить эффективность проекта MVC3 + Unity - PullRequest
Новая
       3

Пытаясь повысить эффективность проекта MVC3 + Unity

2 голосов
/ 21 февраля 2012

У меня есть проект MVC3, который использует Unity для внедрения зависимостей.

Существует основной проект MVC3, библиотека классов «домен», которая находится между MVC3 и уровнем данных, и набор библиотек классов, составляющих уровень данных.

(MVC3) - (домен) - (уровень данных)

Это пример одного из конструкторов служб в классе домена: 

public DomainModelCacheServices(
    Data.Interface.ICountryRepository countryRepository,
    Data.Interface.ILanguageRepository languageRepository,
    Data.Interface.ISocialNetRepository socialNetRepository
)

Каждый раз, когда вызывается контроллер с DomainModelCacheServices в своем конструкторе, создается новый объект DomainModelCacheServices, а также три класса репозитория в конструкторе DomainModelCacheServices.

Я не могу поверить, что это эффективно!

Что еще хуже, так это то, что класс DomainModelCacheServices является классом кеша. Он загружает списки данных, которые никогда не меняются, и хранит их как статические. Но для каждой ссылки все еще необходимо создать три класса репозитория!

Если я предоставлю DomainModelCacheServices время жизни одиночного (навсегда), я должен убедиться, что он поточно-ориентирован, а если придет день, когда я получу сотни обращений, будет много блокировок.

Я мог бы изменить конструктор на это: 

    public DomainModelCacheServices(
        IServiceLocator serviceLocator
    )

Я не знаю почему, но это выглядит не так. Конструктор теряет смысл, и мне приходится ссылаться на Unity в классе домена и каким-то образом информировать класс домена о ServiceLocator, принадлежащем приложению MVC3. Может быть, ослабленная муфта может быть слишком ослаблена?

Может быть, создание всех этих классов не так неэффективно, как кажется, мне не стоит об этом беспокоиться?

Было бы неплохо, если бы Unity поддерживал параметры конструктора «Lazy». Но это не так.

Итак, есть ли какие-нибудь идеи о том, как сделать проект MVC3 + Unity более эффективным, особенно при разработке модели предметной области?

Спасибо за чтение!

Ответы [ 2 ]

1 голос
/ 21 февраля 2012

Кэш должен определяться не на уровне домена, а на уровне реализации репозиториев (например, в DAL).Так, например, ICountryRepository должно иметь две реализации в DAL: CountryRepository и ChachedCountryRepository .Они должны быть подключены как декораторы в Unity (CountryRepository находится внутри ChachedCountryRepository).CachedCountryRepository проверит, находятся ли данные в кеше, и если нет, то передаст вызов внутреннему CountryRepository.

Создание объектов не дорого и не слишком заботится о проблемах, таких как кэширование.правильно определено.

0 голосов
/ 21 февраля 2012

Великие рассуждения.

Однако создание объектов обходится дешево. Я бы не стал создавать синглтон, поскольку вы уже кэшируете все объекты в статических полях. Текущий подход легко понять.

У меня есть еще один вопрос для вас:

Почему вы не кэшируете в своих классах хранилища?

Репозитории отвечают за данные, и вся обработка данных должна быть прозрачной для всего остального. Это также делает все проще, поскольку они несут ответственность за обновление источников данных. Как вы держите кэш в синхронизации с изменениями сегодня? Через доменные события?

Я бы создал класс кэша, который я бы использовал в качестве частного поля в хранилище.

...