Nette: Модели vs vendor lib

У меня есть несколько моделей, которые я выполнял некоторое время в каждом проекте песочницы, и это заставило меня задуматься. В чем разница между несколькими моделями с постоянной реализацией Vs. моя собственная библиотека, которая в теории содержала бы такие же файлы.Nette: Модели vs vendor lib

Вопрос №1: Есть ли разница во времени исполнения? & Загрузка страницы между несколькими объектами модели и теми же объектами из библиотеки?

Вопрос №2: Почему я должен использовать библиотеку вместо нескольких моделей (или наоборот)?

Вопрос № 3: Если нет каких-либо различий в этих двух, должен ли я создать свою собственную библиотеку только для более легкой реализации композитора или какой-то вариант персонализированной песочницы git rep с моделями - лучший вариант?

источник

2016-08-19 Vladimir Litovkin

Что вы подразумеваете под «моделями»? –

Классы, NetteObjects, например, у меня есть модель Log, которая реализована в basePresenter и Logs, что мне нужно для регистрации. Или у меня есть объект, который расширяет Nette/Object и в основном является родителем других классов в моем приложении/модели. Он содержит множество полезных функций и методов проверки. Далее, пример из последнего приложения, я создал календарь, в котором было много разных функций, связанных с датой и временем, а также было использовано для создания структуры данных для интерфейса. –

Я вижу. Может быть полезен некоторый минимальный код: что вы хотите загрузить с какого места? –

Это ничтожно мало. Ваши классы всегда должны быть включены. Не имеет значения, включены ли они автозагрузкой композитора или nette RobotLoader.
Если конкретная функциональность может помочь другим людям, вы можете много помочь кому-то, создав библиотеку. Если это слишком специфично для вашего приложения, перейдите в каталог libs или что-то прямо в приложении, вы можете изменить функционал более легко позже, если это необходимо.
Я бы сказал, что оба. Создание и поддержка песочницы намного проще, чем совместное использование несколькими проектами. С помощью lib вы должны, например, поддерживать обратную совместимость. Кроме того, если у вас много несвязанных классов, нет смысла создавать одну библиотеку из них. Reather создает больше библиотек, реализующих определенные функции. Например, класс ведения журнала, который будет содержать ваш LogModel. Но прежде чем вы начнете, попробуйте выполнить поиск пакетов, если вам уже не нужен lib. Для ведения журнала Монолог может быть полезен. Ваш календарь - отличный кандидат для библиотеки.

источник

2016-08-19 22:24:32

Ах, теперь я понял! Итак, в основном, основными вопросами являются вопрос о том, является ли это обычным для определенного приложения И связаны ли классы. Например, если я перехожу на какой-то CMS, это должно быть lib, но если мы говорим о чем-то вроде, скажем, какого-то средства миграции базы данных, которое я планирую использовать как часть CMS, но иногда как независимый модуль для других приложений, я должен держать его как класс, а не искать lib для этой конкретной функции. Верный? –

На мой взгляд, CMS слишком сложна, чтобы быть lib. С другой стороны, идея goot состоит в том, чтобы иметь больше библиотек с определенной функциональностью, например, класс db, пейджер и т. Д., Из которых будет состоять CMS. Конечно, вы можете опубликовать свое приложение CMS в github, чтобы предложить его другим людям. Инструмент миграции базы данных - отличный пример для lib, установленного вместе с композитором, потому что вы можете поделиться им с другими приложениями. Не должно быть много функциональности, специфичной для одного приложения. Но, например, UserModel, несмотря на то, что он используется одинаково во всех ваших приложениях, не является хорошим выбором для lib. Надеюсь ты понимаешь. –

Даже если я не понимаю вашу ситуацию полностью, я постараюсь ответить как можно лучше:

1) не совсем, это класс самозарядные, независимо от того, где он находится

2) Я рекомендую переместить код в библиотеку, когда вы обнаружите, что некоторые классы имеют общее значение, которые могут быть абстрагированы в какой-либо каталог, например

FileManager
ImageResizer
ACL
CMS
...

3) Если ваш код является стабильным и последовательным (= не изменяется в приложении), Я бы пошел на пакет. Если вам нужно настроить его, я бы сохранил его для каждого приложения.

Все зависит от ваших конкретных классов. Лучше всего увидеть весь проект и проблемы, которые у вас есть.

источник

2016-08-19 22:27:45

ответ

Смежные вопросы