jixstes
Новичок
Здравствуйте. Столкнулся с архитектурными проблемами при разработке - опыта сборки вообще нет.
Система абстрактно: главный класс - гл. контроллер - гл. контроллер вида - конкр модель - классы-транзакции.
Вопросы:
1. Залогировать действий в транзакциях можно иньецируя туда объект логгера. Модель может это сделать, но тогда объект логгера пропускать через всю цепочку выше, например, передавая вообще объект с глобальными настройками и с логом? Или на нижних звеньях лучше выбрасывать исключения illegalargument и null и т.п., а логировать только в ключевых местах? Но тогда нет дебажной информации...Зато можно потестировать и просто переносить в другое приложение и зависимости от логгера нет. Или использовать встроенный в php наблюдатель?
2. Допустим, есть тот же уровень лога. Хранится в файле настроек. Настройки читает конвертер. Вопрос, кто должен приводить текст к формату уровня логгера т.к. нужно же точно ограничить возможные - значит нужна сущность с этими ограничениями. Допустим такой механизм. в зависимости от типов настроек конвертер читает их и по ключу рефлексией вызывает сеттеры объекта который будет хранить значение ключей. Значение сразу переводить к формату логгера наверное неправильно - формат может поменяться. Где тогда это делать? Помещать настройки еще в один объект, который из текстовых переводит в формат приложения и который гуляет дальше? Но если объект настраивается кем-то как гарантировать, что он в неизменном состоянии дойдет до последнего сегмента? непонятно.
3. Например, два класса работают с разными файлами настроек. Методы чтения и записи можно реализовать в них, но можно передать объект для этой задачи. Насколько самостоятелен должен быть класс? Метод чтения из файла входит в обязанность класса или это обязанность сущности работы с файлами. Так можно бесконечно же расслаивать. Наверное, все же другой класс более гибок т.к. может , например, понадобиться конверсия абсолютный\относительный путь.
4. Например, контроллер для получения по апи инфы о пользователях требует модели регистратора и класса для работы с апи. Кто приведет контроллер в валидное состояние? создать "экземпляр" приложения на основе конфигуратора, который уже запускает контроллеры?
5. вид логирует действия модели. Модель к виду обратиться не может и просто прикрепить слушатель между ними нельзя. тогда в модели сделать поле, которое обновляется, связать это поле и контроллер, а он уже обновляет вид? это, наверное, для десктопа больше.
сорри на большой текст.
спасибо.
Система абстрактно: главный класс - гл. контроллер - гл. контроллер вида - конкр модель - классы-транзакции.
Вопросы:
1. Залогировать действий в транзакциях можно иньецируя туда объект логгера. Модель может это сделать, но тогда объект логгера пропускать через всю цепочку выше, например, передавая вообще объект с глобальными настройками и с логом? Или на нижних звеньях лучше выбрасывать исключения illegalargument и null и т.п., а логировать только в ключевых местах? Но тогда нет дебажной информации...Зато можно потестировать и просто переносить в другое приложение и зависимости от логгера нет. Или использовать встроенный в php наблюдатель?
2. Допустим, есть тот же уровень лога. Хранится в файле настроек. Настройки читает конвертер. Вопрос, кто должен приводить текст к формату уровня логгера т.к. нужно же точно ограничить возможные - значит нужна сущность с этими ограничениями. Допустим такой механизм. в зависимости от типов настроек конвертер читает их и по ключу рефлексией вызывает сеттеры объекта который будет хранить значение ключей. Значение сразу переводить к формату логгера наверное неправильно - формат может поменяться. Где тогда это делать? Помещать настройки еще в один объект, который из текстовых переводит в формат приложения и который гуляет дальше? Но если объект настраивается кем-то как гарантировать, что он в неизменном состоянии дойдет до последнего сегмента? непонятно.
3. Например, два класса работают с разными файлами настроек. Методы чтения и записи можно реализовать в них, но можно передать объект для этой задачи. Насколько самостоятелен должен быть класс? Метод чтения из файла входит в обязанность класса или это обязанность сущности работы с файлами. Так можно бесконечно же расслаивать. Наверное, все же другой класс более гибок т.к. может , например, понадобиться конверсия абсолютный\относительный путь.
4. Например, контроллер для получения по апи инфы о пользователях требует модели регистратора и класса для работы с апи. Кто приведет контроллер в валидное состояние? создать "экземпляр" приложения на основе конфигуратора, который уже запускает контроллеры?
5. вид логирует действия модели. Модель к виду обратиться не может и просто прикрепить слушатель между ними нельзя. тогда в модели сделать поле, которое обновляется, связать это поле и контроллер, а он уже обновляет вид? это, наверное, для десктопа больше.
сорри на большой текст.
спасибо.
Последнее редактирование: