Comments 10
Это всё хорошо, а нагрузочное тестирование различных вариантов проводились?
Тестирования пока не было, т.к. сделан только рабочий демо проект, в перспективе будет. Но собственно ради чего все и началось, сайт с моделью построенной на базе ContentTypeDefinition жутко тормозил. Когда прошелся профайлером: для построения одной страницы из списка 12 картин, требовалось порядка 600 запросов к базе. После оптимизации удалось снизить до 160, но это все равно много, поэтому было принято решение сделать исследование в пользу отдельного построения модели, независимой от Orchard.
«Orchard.CMS одна из популярных свободных open source систем управления веб контентом на базе .NET.»
Всего 20K загрузок с июля месяца.
Всего 20K загрузок с июля месяца.
В компании проводили анализ и сравнение CMS-к на ASP.NET, как проприетарных, так и свободных. Umbraco и Orchard.CMS лучшие свободные решения в области веб-контент менеджмента построенные на .NET.
Чтобы не быть голословным: Orchard и Umbraco в первой пятерке (язык=eng): Галерея веб-CMS на Microsoft
Статья в целом полезная, хотя и немного странная. Не хватает информации, которая логически бы связывала ее части друг с другом. Например, в самом начале вы пишите:
> Orchard не предусматривает прямого доступа к NHibernate по умолчанию
хотя зачем это может понадобится из информации во введении непонятно. К тому же позже как раз показано, как конфигурировать NH напрямую. Так что тут либо следовало написать, что подразумевается под «по умолчанию», либо использовать другую формулировку.
Первая часть начинается вроде бы стройно: показаны проблемы при использовании типов содержимого (это более распространненный перевод для content type, чем контентный тип). После этого в результатах применения подхода с типами содержимого написано:
> Orchard.CMS базируется на контентных частях и контентных типах. Текстовые разделы, блоги, html части и так далее – в большинстве случаев контентные типы или контентные части. Смешивание данные представления и доменной модели приложения – грубое нарушение инкапсуляции.
Это звучит как 3 несвязанных друг с другом предложений. Orchard.CMS — это прежде всего CMS, как бы смешно это ни звучало, и указанные сущности (текстовые разделы, блоги, html части) являются скорее ее моделью, а не представлением. С последним предложением в целом можно согласится (хотя часто в представлениях можно использовать модель напрямую, напр. когда это не требует изменений модели в простых views и не влечет проблем с производительностью), но как это связано с предыдущими двумя предложениями, непонятно.
> Перенести доменную модель и бизнес логику, выполненные в контексте Orchard, на другую CMS или чистый MVC – это огромная работа.
Возможно это и огромная работа, но как это относится к результатам применения подхода к построению модели с помощью типов содержимого, под которым эти пункты сгруппированы? Т.е. если до этого были указаны скорее минусы подхода, то это уже скорее плюс, т.к. использование типов содержимого позволяет сэкономить время, которое будет потрачено для других указанных подходов.
> Тестирование, его придется выполнять в рамках Orchard контекста.
Имеется ввиду юнит-тестирование? Если да, то какие проблемы это влечет? Orchard построен на интерфейсах и очень гибок в этом смысле. Да придется потратить больше времени на создание mock-ов для Orchard-овских сущностей, но его также придется потратить и при использовании других подходов. Т.е. опять недостаточно информации.
После этого вскользь упоминается паттерн Record и начинается вторая часть об использовании NH напрямую. Как вторая часть связана со второй? Какой подход вы в итоге использовали? Проанализировав код конфигурации NH можно сделать вывод, что вы скорее всего используете собственную модель, вместо типов содержимого:
> cfg.Mappings(x => x.FluentMappings.AddFromAssemblyOf());
но это все неявно. Нужно было более детально описать используемый для статьи тестовый сценарий, тогда бы она выглядела как цельная статья. Сейчас она больше похожа на несколько статей из справочной документации.
Не относитесь к этой критике негативно. Чем больше будет статей про Orchard, тем лучше, на мой взгляд. Это хорошая, хотя и своеобразная CMS, написанная и поддерживаемая грамотными людьми. Поэтому в целом я считаю инвестиции в нее оправданными и все последние свои проекты делаю на Orchard-е. Те, кто работал с Orchard-ом скорее всего поймут посыл статьи, но хотелось бы также, чтобы и новички не испугались ее использовать после прочтения. Для этого я и добавил сюда этот комментарий.
> Orchard не предусматривает прямого доступа к NHibernate по умолчанию
хотя зачем это может понадобится из информации во введении непонятно. К тому же позже как раз показано, как конфигурировать NH напрямую. Так что тут либо следовало написать, что подразумевается под «по умолчанию», либо использовать другую формулировку.
Первая часть начинается вроде бы стройно: показаны проблемы при использовании типов содержимого (это более распространненный перевод для content type, чем контентный тип). После этого в результатах применения подхода с типами содержимого написано:
> Orchard.CMS базируется на контентных частях и контентных типах. Текстовые разделы, блоги, html части и так далее – в большинстве случаев контентные типы или контентные части. Смешивание данные представления и доменной модели приложения – грубое нарушение инкапсуляции.
Это звучит как 3 несвязанных друг с другом предложений. Orchard.CMS — это прежде всего CMS, как бы смешно это ни звучало, и указанные сущности (текстовые разделы, блоги, html части) являются скорее ее моделью, а не представлением. С последним предложением в целом можно согласится (хотя часто в представлениях можно использовать модель напрямую, напр. когда это не требует изменений модели в простых views и не влечет проблем с производительностью), но как это связано с предыдущими двумя предложениями, непонятно.
> Перенести доменную модель и бизнес логику, выполненные в контексте Orchard, на другую CMS или чистый MVC – это огромная работа.
Возможно это и огромная работа, но как это относится к результатам применения подхода к построению модели с помощью типов содержимого, под которым эти пункты сгруппированы? Т.е. если до этого были указаны скорее минусы подхода, то это уже скорее плюс, т.к. использование типов содержимого позволяет сэкономить время, которое будет потрачено для других указанных подходов.
> Тестирование, его придется выполнять в рамках Orchard контекста.
Имеется ввиду юнит-тестирование? Если да, то какие проблемы это влечет? Orchard построен на интерфейсах и очень гибок в этом смысле. Да придется потратить больше времени на создание mock-ов для Orchard-овских сущностей, но его также придется потратить и при использовании других подходов. Т.е. опять недостаточно информации.
После этого вскользь упоминается паттерн Record и начинается вторая часть об использовании NH напрямую. Как вторая часть связана со второй? Какой подход вы в итоге использовали? Проанализировав код конфигурации NH можно сделать вывод, что вы скорее всего используете собственную модель, вместо типов содержимого:
> cfg.Mappings(x => x.FluentMappings.AddFromAssemblyOf());
но это все неявно. Нужно было более детально описать используемый для статьи тестовый сценарий, тогда бы она выглядела как цельная статья. Сейчас она больше похожа на несколько статей из справочной документации.
Не относитесь к этой критике негативно. Чем больше будет статей про Orchard, тем лучше, на мой взгляд. Это хорошая, хотя и своеобразная CMS, написанная и поддерживаемая грамотными людьми. Поэтому в целом я считаю инвестиции в нее оправданными и все последние свои проекты делаю на Orchard-е. Те, кто работал с Orchard-ом скорее всего поймут посыл статьи, но хотелось бы также, чтобы и новички не испугались ее использовать после прочтения. Для этого я и добавил сюда этот комментарий.
Спасибо большое за развернутый комментарий. Соглашусь, что статья получилась сложная и узкоспециализированная.
Сделать полноценный туториал для новичков не удалось, т.к. материал возрос бы раза в 3 в 4, а это довольно затратно по времени. Постарался донести кратко основные идеи, которые вы абсолютно верно отметили, и представил готовый демо проект.
Пока что я не реализовал данную модель в бою, но в планах есть такое. Много всего еще не затронуто здесь — это и кеширование модели и страниц, это и интеграция виджетов и доменной модели в плане архитектуры (грамотная разбивка на модули, расширяемость, mapping).
Orchard.CMS на мой взгляд имеет одну из самых сложных кривых обучения в сравнение с Ektron, Sitefinity, Umbraco или NopCommerce. Если делать выбор в пользу открытой CMS, я бы остановил свой выбор на Umbraco, а для E-Commerce — NopCommerce.
Сделать полноценный туториал для новичков не удалось, т.к. материал возрос бы раза в 3 в 4, а это довольно затратно по времени. Постарался донести кратко основные идеи, которые вы абсолютно верно отметили, и представил готовый демо проект.
Пока что я не реализовал данную модель в бою, но в планах есть такое. Много всего еще не затронуто здесь — это и кеширование модели и страниц, это и интеграция виджетов и доменной модели в плане архитектуры (грамотная разбивка на модули, расширяемость, mapping).
Orchard.CMS на мой взгляд имеет одну из самых сложных кривых обучения в сравнение с Ektron, Sitefinity, Umbraco или NopCommerce. Если делать выбор в пользу открытой CMS, я бы остановил свой выбор на Umbraco, а для E-Commerce — NopCommerce.
Sign up to leave a comment.
Использование возможностей NHibernate в Orchard.CMS