Обновить
2
ITweb@ITweb

Пользователь

1
Подписчики
Отправить сообщение
Не совсем, этого уже нет начиная с 4.5
Спасибо, тоже порылся, похоже Olimex запилили специальную сборку Debian с поддержкой Mono
Выглядит очень не плохо, а есть ли возможность поднять на ней Mono?
Тогда заголовок получается желтоватый.
А причем тут кластер?
Ахаха, перестаньте смешить. За такое «архитектору» надо по башке дать.
Если уж так необходимы разные контроллеры или экшены для разных клиентов, не проще ли сделать свою реализацию ActionInvoker, который будет ориентироваться, например, на некий атрибут в котором указывать для DisplayMode этот экшен?
Не хочу обидеть автора, но даже я не имея магазина, ничего нового не узнал. Таких статей за последние 5 лет, был миллион. Поскольку вы имеете солидный опыт в ecommerce, я бы лучше выбирал очень узкие темы и описывал все тонкости.
Наткнувшись в статье про оптимизацию БД на SELECT * FROM сразу бросил читать это…
А на SQL лицензии планируются?
Я согласен, что не бывает единственно верного решения, всегда есть нюансы. Но к примеру у нас в проекте (приличный хайлоад) таких ситуаций не возникало.
Ну мне кажется что управление транзакцией в БД должна управлять сама БД, но это мое мнение.
В разных ситуациях по разному, если приложение не критично по производительности, то такой вариант очень уместен в силу легкости его поддержки, читаемости и т.д., но когда встает вопрос производительности, то этот подход уже не катит.
Даст более быстрый код (не для всех проектов это принципиально), легче отлаживать и искать баги, ну и соответственно нет тех проблем про которые статья.
Конкретно в вашем примере вместо одного конекта и запроса к БД получается 2.

Мне кажется конкретно в вашем случае транзакции в коде только добавляют проблем.
Каюсь, сейчас освежил память, действительно, DTC зависит от кол-ва конектов.
Если честно, то я давно с этим сталкивался, но по моему распределенные транзакции возникали если в коннекте к БД был указан не локальный адрес.
Если честно, я не вижу смысла выносить логику GetOrCreateCompany в код, это гораздо легче и правильней делать на стороне БД.
Наш DBA только при упоминании использования транзакций в коде, хватается за раскаленную кочергу.
когда БД на другой машине, TransactionScope работает через distributed transactions, а настроить ее и заставить работать то еще удовольствие. Ну и на быстродействии это сказывается очень сильно. Для более менее хайлоада это вообще табу.
причем этот код без доп. телодвижений и проблем работает только в случае нахождения БД на том же компьютере.
Низнаю как сейчас, работали с паркингом года 3 назад.
1. В договоре было прописано 4 часа даунтайма
2. Тех. поддержка работает с 10 до 19, только в будни и только по email.

Что не совсем сочетается с решениями для бизнеса.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность