Razor Pages — новая фича, появившаяся в Core.Net 2.0. Razor Page — это страница, состоящая из стандартной разметки (View) и бэкенд класса. В каком то смысле напоминает Web Forms только без поддержки сохранения состояния. Преимущество такого решения очевидно — мы избавляемся от ненужной прослойки — модели страницы (модель данных в виде например Entity это само собой). Бэкенд страницы является и контроллером и моделью — классика ООП — инкапсуляция данных и методов работы с ними в одном объекте. В конце концов модель страницы — это просто класс, нет никаких причин почему этим классом не может быть контроллер.

Иными словами, Razor Pages — более вменяемое решение для веба чем MVC, теперь мы имеем дело с традиционным и логичным понятием «страница» а не с контролерами и моделями разбросанными по всему проекту. Но поскольку .NET будет развиваться по направлению Core.Net то вряд ли Razor Page появятся в стандартном фреймворке, несмотря на то что ближайшие годы большинство проектов будет оставаться на стандартном .NET. Тем не менее можно изобразить функциональность Razor Pages и на стандартном фреймворке.

Опенкарт — один из самых распространенных интернет-магазинов. Во многих случаях возникает задача интеграции со складской учетной системой (чаще всего с 1С).

Интеграция предполагает, как минимум, передачу заказов с ИМ в складскую систему для их обработки и отправки товаров покупателю и обновление количества товаров в ИМ в соответствии с реальным наличием на складе.

Также часто стоит задача засинхронизировать сами товары, их параметры, фотографии и так далее.

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

Для решения данной проблемы создан модуль к Опенкарт который расширяет API опенкарта позволяя вносить изменения только на стороне учетной системы.

Модуль бесплатный с открытым кодом, расположен на гитхабе.

Поскольку развитие технологий привело к тому, что у каждого программиста теперь есть собственный компьютер, в качестве побочного эффекта имеем тысячи разнообразных библиотек, фреймворков, сервисов, API и т.д. на все случаи жизни. Но когда этот случай жизни наступает, возникает проблема — что их этого использовать и что делать если оно не совсем подходит — переписывать, писать с нуля свое или прикручивать несколько решений для разных вариантов использования.

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

Перейдем к конкретной «ходовой» задаче — объектная прослойка для работы с базами данных в PHP. Решений великое множество, начиная от PDO и заканчивая многоуровневыми (и, на мой взгляд, не совсем уместными в PHP) ORM движками.

Поскольку задача написания «аналогов» и «альтернатив» 1С нетривиальная, есть смысл изложить свое видение и ключевые моменты на основе опыта написания своей наколенной поделки. Ну и как бонус услышать критику и вовремя переделать где промахнулся.

По факту, на данный момент 1С занимает подавляющий сегмент в нише учетных систем. Это объясняется рядом причин, в том числе и агрессивным маркетингом. Напомню техническую сторону. 1С в общем виде, состоит как бы из двух физически отдельных частей — собственно платформы (ядра, движка) и так называемой конфигурации.

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

Это плюсы. Но есть и масса минусов. Чтобы не описывать тут можно почитать например здесь.

Попыток вытеснить 1С предпринимается великое множество. Большинство проектов пытается переплюнуть плюсы 1С. Тягаться с огромной корпорацией дело малоперспективное. Продукты, писанные на Делфи или .NET, то есть требующие перекомпиляции, вообще неконкурентные, те, кто пытаются прикручивать в качестве DSL движки javascript или VBA выглядят чуть получше, но в любом случает такие решения могут использоваться в основном если есть штатный программист, чего малый бизнес, как правило, позволить себе не может.

Попробуем подобраться с другой стороны. Не пытаться переплюнуть достоинства 1С а предложить решения тех проблем где 1С имеет минусы.

Поскольку минусы где то уравновешивают плюсы а у нас этих минусов не будет то, даже если у нас не будет плюсов на уровне 1С, сальдо примерно будет такое же.

Как известно, разработка веб-приложений для .NET использует в основном два решения — WebForms и .NET MVC. Наверняка существует что-то еще, но эти два решения от Microsoft — владельца платформы, веб-сервера и среды разработки.

Собственно, наличие только этих двух решений в .NET удобно тем, что ярко демонстрирует разницу между компонентным подходом (WebForms) и MVC. На других платформах тот же расклад, но на PHP, например, такое множество фреймворков, что не всегда можно понять, к какому типу данный фреймворк относится.

Сравнительный анализ вышеуказанных двух .NET решений легко нагуглить, поэтому останавливаться нет смысла.

Пожалуй, главная проблема WebForms — сложность управления HTML-кодом и как следствие проблемы для фронт-энд разработчиков. Сей недостаток “исправили” с помощью .NET MVC, переложив на программиста полное управление, со всеми вытекающими последствиями.

Предполагаю возмущение евангелистов MVC, но тем не менее выскажу свое убеждение: MVC в вебе — как на корове седло. Разумеется, речь не об общей идее разделения кода, представления и данных. Речь о типовой имплементации паттерна в вэбе — контроллеры, экшены и собственно вся архитектура.