nopCommerce 3.00 open source CMS: обзор новых функций, поддержка Windows Azure

[amaz]

> Примечательно, что nopCommerce стала одной из первых open source CMS в мире, которая поддерживает оба данных функционала

Первой, и на данный момент единственной, которая поддерживает оба функционала.

[GraDea]

А что если вендоры начнут загружать одинаковые товары? Можно их как-то склеивать?

[amaz]

нет, у каждого вендора свой продукт

[musuk]

Интеграция с 1С есть?

[amaz]

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

[ydnz]

А русскую локализацию переписали? А то пару лет назад было страшно читать названия пунктов меню
А настройку позволяющую отключать вопрос «Billing Address» не сделали?
CMS отличная, но от реалий российских интернет-магазинов далека. Приходилось много возиться в коде, чтобы упростить процесс заказа

[vassav]

Согласен, процесс оформления заказа довольно замудрен для нашего брата.
Так же при внесения в базу большого количества товара начинает подтормаживать, особенно при включении параметров фильтрации.
А так очень доволен этой CMS использую уже более 2-х лет

[amaz]

Спасибо.

А что именно кроме невозможности отключить billing address вы бы изменили?

[vassav]

Мне, например, нужно было убрать некоторые поля в адресе доставки (страна, регион)

[amaz]

Так это все легко выключается в панели администрирования > configuration > customer settings > address form fields

[vassav]

Спасибо. Не замечал раньше.

[amaz]

> А русскую локализацию переписали? А то пару лет назад было страшно читать названия пунктов меню
Да, вы можете скачать ее для версии 3.00 вот тут www.nopcommerce.com/p/1031/russian-language-pack.aspx

> А настройку позволяющую отключать вопрос «Billing Address» не сделали?
Нет. Пока выключить можно только shipping address

[vassav]

Еще столкнулся с проблемой, когда нужно было было переключить хранение фотографий не в базе а на диске. Тогда посмотрев код немного пришел в ужас: вначале все фотографии из базы считывались в память, а потом сохранялись на диск. Когда их не много, то это не страшно и даже оптимально, а вот когда их больше 10Гб, то это критично.
Интересно, в новой версии это переделали?

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

[amaz]

1. Смена режима с «БД» на «диске» работает все также. Ведь для того, чтобы скопировать картинки с БД на диск, надо их сначала считать их из БД, а потом сохранить на диске. А какие еще могут быть варианты?

2. Не совсем так. При хранении картинок в базе они хранятся ТОЛЬКО в БД. А диске создается превью для того, чтобы его можно было загрузить по URL, и закешировать (не создавать превью на каждый запрос). Что касается нескольких превью ждя одной и той картинки, то на каждый запрошенный размер создается свое превью. Например, если на странице категории показываются картинки размера 100x150px, то и превью такое же создается. Если на странице с корзиной надо показывать картинки размера 50x50px, то и превью будет создана соответствующего размера

[vassav]

Ведь для того, чтобы скопировать картинки с БД на диск, надо их сначала считать их из БД, а потом сохранить на диске. А какие еще могут быть варианты?

Согласен что их нужно прочитать из БД, но не сразу все, а по одной и без использования ORM.
В версии 2.8 код для сохранения на диск:

//Чтение из базы всех фотографий
var pictures = this.GetPictures(0, int.MaxValue);
foreach (var picture in pictures)
{
    var pictureBinary = LoadPictureBinary(picture, !value);
//Сохранение фотографии
    UpdatePicture(picture.Id,
                    pictureBinary,
                    picture.MimeType,
                    picture.SeoFilename,
                    true,
                    false);
   
}

В результате выполнения этого кода, если фотографий очень много, я получал OutOfMemoryException, т.к. 10Гб фотографий он не мог считать в память.
Даже, если переделать этот код, и считывать не все сообщения в список, а по одному, результат будет тот же (при считывании объекта из базы DbContext начинает отслеживать его изменения и следовательно, пока жив DbContext будут живы и все объекты).
Оптимальным решением будет использовать чистый ADO.NET и DataReader.

[amaz]

Спасибо. EF с больших количеством записей (тяжелых записей) и кешированием не очень дружит. Аналогичная есть проблема с генерацией XML файлов для Google Product Search или экспорта большого кол-во продуктов.

[vassav]

Большое количество записей еще не так критично как записи большого размера. А при работе с большим количеством записей в EF можно отключить отслеживание объектов (NoTracking)

[vassav]

А можно как-то отключить постоянную проверку наличия превью при каждом получении ссылки на нее?

[amaz]

Вы хотите, чтоб оно (превью) постоянно заново генерировалось? В таком случае вам придется немного изменить логику метода «GetPictureUrl» у класса PictureService. Хотя возникает вопрос, а зачем?

[vassav]

Нет, я хочу уменьшить нагрузку на диск и сервер.
Сейчас, при каждом вызове метода «GetPictureUrl» загружается содержимое файла в память (в не зависимости от типа хранения база/диск), проверяется наличие превью нужных размеров (в случае отсутствия последних создает их) и возвращает ссылку на нужный превью.
Я же предлагаю подправить метод: один раз проверять наличие превью и сохранять результат в базу, либо делать это при создании/редактировании продукта, а если картинка отсутствует возвращать линк на картинку по умолчанию.
Еще как вариант, сделать отдельный Task, который будет проверять наличие всех необходимых превью и создавать их по необходимости

[amaz]

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

[ydnz]

Спасибо! Потестируем.