Меню
Что нового?

native PHP или Laravel для потенциально крупного проекта?

grigori написал(а):
есть DTO, который мапится на поля таблицы, и модель, которая создает этот класс при работе с базой,
и есть еще модель, которая принимает эту модель для получения VO
в параметре ты прописываешь не тип первой модели, а тип интерфейса, у которого есть единственная реализация - модель, которая работает с базой - ведь ты, типа, правильный, и в тестах ты хочешь подменить эту модель
Нажмите для раскрытия...
«Модель создает этот класс при работе с базой» — что это? «Модель принимает эту модель для получения VO» — что это? Что такое вообще «модель» в твоём понимании? DTO, VO, Entity, ActiveRecord, DataMapper? Почему модель вообще лезет в базу? Это из разряда «мыши плакали, кололись, но продолжали есть ActiveRecord»? Для entities, value objects, DTO никакие интерфейсы, тем более 1-в-1, не нужны. Для сервисов — по ситуации.
 
давайте дальше по теме - вот можете сказать как определить разработчик способен выполнить то или иное задание стоит ли его брать?
 
@Rednaxela-1, по ответам на вопросы на собеседовании, по решению тестового задания, по знанию смежных технологий
 
grigori написал(а):
сервисы лезут в базу, сервисы :)
Нажмите для раскрытия...
Так а почему ты сервис называешь моделью? И если интерфейс только мешает, то почему просто не выкинуть его нафиг? Что именно там так часто добавляется, что интерфейс лень поддерживать?

Я вот всегда добавляю интерфейс для репозитория, но там всегда два метода: find(): Foo, save(Foo), поэтому его не приходится каждый раз дорабатывать.
Но я нередко ленюсь добавлять интерфейсы для различных QueryService, если нужно делать разные выборки, примерно как тут: https://github.com/VaughnVernon/IDD...pplication/calendar/CalendarQueryService.java
Мотивация тут ещё такая, что unit-тесты с участием query services мне обычно никогда не нужны, тут нужны интеграционные или полноценные функциональные тесты, и тут уже что-то мокать не нужно, нужно честно делать выборку из БД.
Плюс если соблюдать адекватный нейминг без суффикса -Interface, то final class можно достаточно безболезненно заменить на соответствующий интерфейс, если реально появится какое-то ещё хранилище помимо MySQL, например.
 
@Rednaxela-1, главное что дает фреймворк - это структуру проекта (что уже заложено в самом слове фреймворк) - без фреймворка ваш проект превратится в ад гораздо быстрее чем с. Так что если проект "потенциально крупный" тем более лучше использовать фреймворк. Скорость запросов зависит от умения писать запросы, а не от фреймворка
 
@Rednaxela-1 фреймворк тебя ничем не ограничивает, это просто кусок готового функционала для часто встречающихся задач. Никто не принуждает его использовать на 100%. На моём последнем большом проекте на laravel было лишь рест апи на java, ruby и php из них брались данные, а функционал фреймворка для работы с базой данных вовсе не использовался.
 
@Rednaxela-1, открою секрет. Понимание того что нужно формируется у заказчика только после получения готового продукта.
Иногда он упертый и хочет чтобы гланды удалял проктолог. Послав нафиг ларинголог , он только потом может согласиться . Да нужно было делать по вашему.

Нативный пхп 90% времени пишешь функционал,который есть во фреймворке. Считая, что ты его сделаешь лучше/гибче /быстрее чем эти идиоты.
Получаешь такую кашу,которая фиг расширяется/ никто в ней не разбирается. Тот кто ее родил не может быть сокращен.

Имхо правильнее .Быстрый прототип , чтобы понять бизнес идея работает или нет. Возможно даже на готовой кмс.
Главное, чтобы ее можно слепить было за 1-2 месяца.

Ну а дальше допил / переписывание на фреймворке.

На нативном пхп в конце концов возможно придется переписать проблемные в плане производительности места.
 
Если:
  • Делаешь проект для себя
  • Хочешь лучше освоить PHP
  • Много свободного времени
Можно делать как угодно, в том числе взяться и за написание своего фреймворка.

Если же:
  • Делаешь проект для заказчика
  • Над проектом будет работать другие люди
То лучше использовать распространенный фреймворк.

Исключение: сверх-крупные проекты. Например социальная сеть вконтакте, для которой даже свою модификацию php языка сделали - kphp
 
Последнее редактирование:
facebook выпускает hhvm как модификацию php для ускорения, а php team на его основе выпускают ng, и php7 обходит hhvm по скорости, потому что уделяют внимание оптимизации на реальных задачах, а не компиляции,
и теперь все, кто ушли в подмножество, должны все это выкинуть и переписывать назад на php
 
@grigori, подозреваю, что чем больше в новом коде будет использоваться строгая типизация из php7, тем эффективнее будет компиляция, и когда-нибудь и в php появится JIT.

Кстати, от hhvm есть очень большая побочная польза - они написали спецификацию языка php, со всеми нюансами фактической (единственной на тот момент) реализации.
 
От нее огромная польза. Без нее не было бы этого многократного роста производительности, и php постепенно ушел бы в небытие как perl и рельсы на фоне развития JS. Я о другом.
 
Войдите или зарегистрируйтесь для ответа.
Сверху