Задать вопрос
  • MVC (PHP): правильно ли понимаю слои?

    @Akela_wolf
    Extreme Programmer
    Модель - собственно данные с которыми работает программа. Они составляют основу программы и, вообще говоря, ничего не должны знать о контроллерах и прочем взаимодействии с пользователем. Теоретически к слою данных можно обратиться откуда угодно - хоть из скрипта, хоть через рест, хоть через вебсокеты, хоть через интерфейс десктопного приложения и т.д. Сервисы, в которых у вас бизнес-логика находятся рядом с моделью и составляют ядро приложения. Либо этих сервисов нет и вся бизнес-логика в модели (такое тоже может быть)

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

    Хранение - слой, отвечающий за сохранение данных модели в БД/файлы/куда-нибудь еще. Модель, как чистая бизнес-логика, обычно не должна знать про то как и куда её данные сохраняются. Есть просто интерфейсы - прочитать данные, записать данные. А за ними реализация работы с БД и прочими хранилищами.

    Это я написал так, как полагается делать в теории, как описывает Роберт Мартин в книге "Чистая архитектура". Понятно что в реальности (а мы говорим про PHP), все это вряд ли будет настолько четко разделено в коде. Но в голове вот такое разделение на Контроллер(представление) - Модель - Хранение я держать советую.
    Ответ написан
  • Зачем в интерфейсах логика?

    @Akela_wolf
    Extreme Programmer
    1. Класс может иметь поля (состояние), интерфейс нет. Вот это первое и главное различие
    2. Интерфейс не может иметь протектед и приватные методы, класс - может.

    А вообще в интерфейсы можно писать методы с реализацией, чтобы прямо в интерфейсе задокументировать что "вот этот метод он как бы не самостоятельный метод, он реализуется поверх других методов интерфейса. Но он часто используется, он удобный, поэтому вот - держите прямо в интерфейсе". Ну и при необходимости в классе можно перекрыть этот метод, например, чтобы предоставить оптимизированную версию.

    Еще посмотрите extension functions в Котлине - придуманы с той же идеей, хотя имеют свои преимущества (легко добавить к существующему интерфейсу/классу) и недостатки (нельзя перекрыть в производном классе)
    Ответ написан
    Комментировать
  • JDBC, почему нельзя использовать один Connection для нескольких методов в разрезе многопоточности?

    @Akela_wolf
    Extreme Programmer
    1. Синхронизация между потоками. Если оба потока начнут посылать запросы в БД через один коннекшен - могут начаться спецэффекты (тут нужно курить "потокобезопасность" коннекшена)
    2. Транзакции в БД. Запросы через один коннекшен будут в одной транзакции. Если для вас это ОК - то все ок. Если же разные потоки требуют разных транзакций - то придется каждому потоку выдавать свой коннекшен.
    100 пользователей и 100 потоков - это слегка разные вещи. Я бы в первую очередь посмотрел сюда - по потоку на каждого пользователя для меня выглядит подозрительно. Если это веб, то у вас от каждого пользователя приходит запрос, обрабатывается, отправляется ответ. Все. Если от пользователей приходит мало запросов - это может делать и один поток. И даже в случае вебсокетов - все равно не нужно держать по потоку на пользователя.
    Ответ написан
    Комментировать
  • Архитектура. Насколько правильно хранить в Entity данные, не относящиеся к БД?

    @Akela_wolf
    Extreme Programmer
    В принципе можно, никто вас за такое не расстреляет. Проблемы - тут все зависит от масштаба вашего приложения и требований к дальнейшей поддержке и изменениям в коде. Чего-то прямо серьезного, что вылезет всегда или почти всегда я в этой истории не наблюдаю.
    Ответ написан
    Комментировать
  • Какие символы разрешить в логине (имени пользователя)?

    @Akela_wolf
    Extreme Programmer
    Я бы разрешил латинские и русские буквы (если сайт включает русскоязычную аудиторию, конечно), пробел, дефис и подчеркивание, а также цифры и спецсимволы. Минимальная длина - 3-4 символа, максимальная длина - на ваше усмотрение (12-16 символов или даже больше).

    Логин регистронезависимый (то есть star guardian и Star Guardian - одинаковый логин). Также сделал бы список запрещенных логинов, таких как root, admin, moderator, support, helpdesk и т.п., которые можно использовать для социальной инженерии, чтобы представиться кем-либо из администрации сайта.
    Ответ написан
    Комментировать