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

[WMix]

можно мокать и прямо по имени класса

можно, мокать только не хочется..

 

[Вурдалак]

есть DTO, который мапится на поля таблицы, и модель, которая создает этот класс при работе с базой,
и есть еще модель, которая принимает эту модель для получения VO
в параметре ты прописываешь не тип первой модели, а тип интерфейса, у которого есть единственная реализация - модель, которая работает с базой - ведь ты, типа, правильный, и в тестах ты хочешь подменить эту модель

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

 

[grigori]

сервисы лезут в базу, сервисы

 

[Rednaxela-1]

давайте дальше по теме - вот можете сказать как определить разработчик способен выполнить то или иное задание стоит ли его брать?

 

[grigori]

@Rednaxela-1, по ответам на вопросы на собеседовании, по решению тестового задания, по знанию смежных технологий

 

[Вурдалак]

сервисы лезут в базу, сервисы

Так а почему ты сервис называешь моделью? И если интерфейс только мешает, то почему просто не выкинуть его нафиг? Что именно там так часто добавляется, что интерфейс лень поддерживать?

Я вот всегда добавляю интерфейс для репозитория, но там всегда два метода: find(): Foo, save(Foo), поэтому его не приходится каждый раз дорабатывать.
Но я нередко ленюсь добавлять интерфейсы для различных QueryService, если нужно делать разные выборки, примерно как тут: https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/application/calendar/CalendarQueryService.java
Мотивация тут ещё такая, что unit-тесты с участием query services мне обычно никогда не нужны, тут нужны интеграционные или полноценные функциональные тесты, и тут уже что-то мокать не нужно, нужно честно делать выборку из БД.
Плюс если соблюдать адекватный нейминг без суффикса -Interface, то final class можно достаточно безболезненно заменить на соответствующий интерфейс, если реально появится какое-то ещё хранилище помимо MySQL, например.

 

[A1x]

@Rednaxela-1, главное что дает фреймворк - это структуру проекта (что уже заложено в самом слове фреймворк) - без фреймворка ваш проект превратится в ад гораздо быстрее чем с. Так что если проект "потенциально крупный" тем более лучше использовать фреймворк. Скорость запросов зависит от умения писать запросы, а не от фреймворка

 

[michelle]

@Rednaxela-1Скорость запросов зависит от умения писать запросы, а не от фреймворка

Добавлю - и умения правильно спроектировать саму базу данных - структуру, индексы.

 

[AmdY]

@Rednaxela-1 фреймворк тебя ничем не ограничивает, это просто кусок готового функционала для часто встречающихся задач. Никто не принуждает его использовать на 100%. На моём последнем большом проекте на laravel было лишь рест апи на java, ruby и php из них брались данные, а функционал фреймворка для работы с базой данных вовсе не использовался.

 

[Betatransfer]

@Rednaxela-1,
Согласен с вами, не зачем переживать.

 

[antson]

@Rednaxela-1, открою секрет. Понимание того что нужно формируется у заказчика только после получения готового продукта.
Иногда он упертый и хочет чтобы гланды удалял проктолог. Послав нафиг ларинголог , он только потом может согласиться . Да нужно было делать по вашему.

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

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

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

На нативном пхп в конце концов возможно придется переписать проблемные в плане производительности места.

 

[HellWalk]

Если:

• Делаешь проект для себя
• Хочешь лучше освоить PHP
• Много свободного времени

Можно делать как угодно, в том числе взяться и за написание своего фреймворка.

Если же:

• Делаешь проект для заказчика
• Над проектом будет работать другие люди

То лучше использовать распространенный фреймворк.

Исключение: сверх-крупные проекты. Например социальная сеть вконтакте, для которой даже свою модификацию php языка сделали - kphp

 

[grigori]

facebook выпускает hhvm как модификацию php для ускорения, а php team на его основе выпускают ng, и php7 обходит hhvm по скорости, потому что уделяют внимание оптимизации на реальных задачах, а не компиляции,
и теперь все, кто ушли в подмножество, должны все это выкинуть и переписывать назад на php

 

[fixxxer]

@grigori, подозреваю, что чем больше в новом коде будет использоваться строгая типизация из php7, тем эффективнее будет компиляция, и когда-нибудь и в php появится JIT.

Кстати, от hhvm есть очень большая побочная польза - они написали спецификацию языка php, со всеми нюансами фактической (единственной на тот момент) реализации.

 

[grigori]

От нее огромная польза. Без нее не было бы этого многократного роста производительности, и php постепенно ушел бы в небытие как perl и рельсы на фоне развития JS. Я о другом.