История изменений

Toxo1, во первых, прошу прощения, что на «ты».

Хочу сказать, что конечно на мой взгляд решать есть ли смысл тащить ОРМ в текущий проект или нет мне кажется надо как минимум консервативно.

Изучение фреймворка займёт определённое время. Вероятно, в неспешном темпе месяца 3. Потом можно решать,стоит ли его использовать в новых проектах. Для старых проектов добавлять фреймворк по моему имеет смысл только тогда когда у программиста ну очень хороший опыт с фреймворком и он понимает что делает.

Так же хотел бы ответить на вашу мысль про унификацию. Действительно, пмсм, поддерживать решение типа MVC проще чем навелосипеженную отдельным программистом «архитектуру» зачастую густо замешанную на глобальные переменные с обильным дублированием и, в худшем случае, с очень высокой связностью. Кажется, действительно будет кое какая экономия за счёт того что не нужно понимать где что искать (или это понять можно тривиально). Но это как мне кажется следствие хороших и плохих «архитектур», а не столько именно унификации. Т.е. мир тяготеет к решениям которые проще и понятнее, когда у сложных нет преимуществ окупающих сложность.

Но что до sql, то по моему он ничуть ни менее «унифицирован» чем orm. Т.е., мне кажется, мы с вами сошлись бы на мнении что найти программиста могущего в тот код который написали вы не сложнее чем такого кто мог бы в тот код что написал я. Т.е. взаимозаменяемость она как бы не страдает от чистого sql. И тут мне кажется всё же играет роль то что не нужно писать sql руками и меньше дублирование кода. Причём всё это имеет такой «квази-декларативный» характер: просмотреть набор правил, названия таблиц и т.п. обычно заметно удобнее чем разбираться в алгоритме или хотя бы в sql запросе. Что ведёт к меньшему количеству ошибок, меньшему объёму кода ну и соотвественно большей производительности труда.

Т.е. по моему унификация - скорее следствие: побеждают хорошо зарекомендовавшие себя решения, ну а их разнообразие ограничено.

Так же хотелось бы отметить такой момент: несмотря на то что анонимус, как кажется, печатает просто какие то наборы слов не несущих особого смысла, всё таки рациональное зерно в его словах есть, по моему мнению. И оно было уже тут высказано после анонимуса ещё раз: орм прослойка довольно сложна, и честно говоря теряет смысл тем дальше чем дальше дело отходит от CRUD. Более продуктивным подходом конечно было бы обернуть ваши запросы в отдельный сервис и как то обобщить немного. Что то вроде

class RentService {
  public function filterRent($poRent) {
    return [
      An::$an_filter->stringOrNull($poRent->contract_number),
      An::$an_filter->dateOrNull($poRent->contract_date),
      An::$an_filter->stringOrNull($poRent->contract_owner_code),
      An::$an_filter->stringOrNull($poRent->description)
    ]
  }

  public function createRent($poRent) {
    $res = An::$an_db->resQuery(
      'INSERT INTO dat_rent'
      . ' (contract_number, contract_date, contract_owner_code, description)'
      . ' VALUES'
      . ' ($1, $2, $3, $4) RETURNING rent_id',
      $this->filterRent($poRent)
    );
  }

  public function updateRent($poRent) {
    An::$an_db->resQuery(
      'UPDATE dat_rent'
      . ' SET contract_number=$1, contract_date=$2, contract_owner_code=$3, description=$4)'
      . ' WHERE'
      . ' rent_id=$5',
      array_merge($this->filterRent($poRent), [$poRent->rent_id])
    );
  }
}

$rentSrv->createRent(json_decode($_POST['rentObj']));

---

Вообще, отвлекаясь от php и уже не лично вам, Taxo1, из серии «самому писать sql» мне больше всего понравился Anorm ( https://playframework.com/documentation/2.6.x/ScalaAnorm ), в изучении очень прост (оно и понятно, sql + немного сверху) и компилятор делает довольно много проверок, что несомненно весомый плюс.

Ещё пробовал myBatis, там запросы в xml пишутся. Идея интересная, но я бы предпочёл полноценный встроенный в язык и проверяемый компилятором при компиляции dsl.

Из подобного я пробовал на реальном проекте Squeryl ( http://squeryl.org/ ) показался очень интересным и удобным. Но если там заблудишься, то без бутылки найти дорогу на свет божий будет трудно.По крайней мере у меня так. Кроме того, емнип, зачастую дб-спецефичных фич в нём не было, что тоже не совсем удобно.

Toxo1, во первых, прошу прощения, что на «ты».

Хочу сказать, что конечно на мой взгляд решать есть ли смысл тащить ОРМ в текущий проект или нет мне кажется надо как минимум консервативно.

Изучение фреймворка займёт определённое время. Вероятно, в неспешном темпе месяца 3. Потом можно решать,стоит ли его использовать в новых проектах. Для старых проектов добавлять фреймворк по моему имеет смысл только тогда когда у программиста ну очень хороший опыт с фреймворком и он понимает что делает.

Так же хотел бы ответить на вашу мысль про унификацию. Действительно, пмсм, поддерживать решение типа MVC проще чем навелосипеженную отдельным программистом «архитектуру» зачастую густо замешанную на глобальные переменные с обильным дублированием и, в худшем случае, с очень высокой связностью. Кажется, действительно будет кое какая экономия за счёт того что не нужно понимать где что искать (или это понять можно тривиально). Но это как мне кажется следствие хороших и плохих «архитектур», а не столько именно унификации. Т.е. мир тяготеет к решениям которые проще и понятнее, когда у сложных нет преимуществ окупающих сложность.

Но что до sql, то по моему он ничуть ни менее «унифицирован» чем orm. Т.е., мне кажется, мы с вами сошлись бы на мнении что найти программиста могущего в тот код который написали вы не сложнее чем такого кто мог бы в тот код что написал я. Т.е. взаимозаменяемость она как бы не страдает от чистого sql. И тут мне кажется всё же играет роль то что не нужно писать sql руками и меньше дублирование кода. Причём всё это имеет такой «квази-декларативный» характер: просмотреть набор правил, названия таблиц и т.п. обычно заметно удобнее чем разбираться в алгоритме или хотя бы в sql запросе. Что ведёт к меньшему количеству ошибок, меньшему объёму кода ну и соотвественно большей производительности труда.

Т.е. по моему унификация - скорее следствие: побеждают хорошо зарекомендовавшие себя решения, ну а их разнообразие ограничено.

Так же хотелось бы отметить такой момент: несмотря на то что анонимус, как кажется, печатает просто какие то наборы слов не несущих особого смысла, всё таки рациональное зерно в его словах есть, по моему мнению. И оно было уже тут высказано после анонимуса ещё раз: орм прослойка довольно сложна, и честно говоря теряет смысл тем дальше чем дальше дело отходит от CRUD. Более продуктивным подходом конечно было бы обернуть ваши запросы в отдельный сервис и как то обобщить немного. Что то вроде

class RentService {
  public function filterRent($poRent) {
    return [
      An::$an_filter->stringOrNull($poRent->contract_number),
      An::$an_filter->dateOrNull($poRent->contract_date),
      An::$an_filter->stringOrNull($poRent->contract_owner_code),
      An::$an_filter->stringOrNull($poRent->description)
    ]
  }

  public function createRent($poRent) {
    $res = An::$an_db->resQuery(
      'INSERT INTO dat_rent'
      . ' (contract_number, contract_date, contract_owner_code, description)'
      . ' VALUES'
      . ' ($1, $2, $3, $4) RETURNING rent_id',
      $this->filterRent($poRent)
    );
  }

  public function updateRent($poRent) {
    An::$an_db->resQuery(
      'UPDATE dat_rent'
      . ' SET contract_number=$1, contract_date=$2, contract_owner_code=$3, description=$4)'
      . ' WHERE'
      . ' rent_id=$5',
      array_merge($this->filterRent($poRent), [$poRent->rent_id])
    );
  }
}

$rentSrv->createRent(json_decode($_POST['rentObj']));