Я думаю, что вход непосредственно в базу данных, как правило, плохая идея, и я бы ее избегал.
Основная причина заключается в следующем: хороший журнал будет наиболее полезен, когда вы можете использовать его для отладки приложения после вскрытия, если ошибка уже возникла и вы не можете ее воспроизвести. Чтобы иметь возможность сделать это, вам необходимо убедиться, что сама регистрация надежна. И чтобы сделать любую систему надежной, хорошее начало должно быть простым.
Таким образом, наличие простого файлового журнала с несколькими строками кода (открыть файл, добавить строку, закрыть файл или оставить его открытым, повторить ...) обычно будет более надежным и полезным в будущем. , когда вам действительно нужно это работать.
С другой стороны, для успешного входа на сервер SQL потребуется, чтобы намного больше компонентов работало правильно, и будет намного больше возможных ситуаций с ошибками, когда вы не сможете записать нужную вам информацию. просто потому, что сама лог-инфраструктура не будет работать. И что-то худшее: сбой в процедуре журнала (например, повреждение базы данных или взаимоблокировка), вероятно, повлияет на производительность приложения, и тогда у вас возникнет ситуация, когда вторичный компонент не позволяет приложению выполнить его основную функцию.
Если вам нужно много анализировать журналы и вам неудобно использовать текстовые инструменты, такие как grep, сохраняйте журналы в текстовых файлах и периодически импортируйте их в базу данных SQL. Если SQL не работает, вы не потеряете любую информацию журнала, и это даже не повлияет на способность приложения работать. Затем вы можете выполнить весь анализ данных в БД.
Я думаю, что это основные причины, по которым я не веду запись в базу данных, хотя я делал это в прошлом. Надеюсь, это поможет.
Проверьте N2 ( http://n2cms.com/ ). Я думаю, что он покрывает большую часть, если не все, ваши требования (я не думаю, что в настоящее время он поддерживает Active Directory). Мы используем N2, и мне очень понравилась его гибкость.
Самостоятельная розетка - это отстой, но то, что вы описываете, в значительной степени именно то, что я собираюсь выпустить по цене 79 долларов за штуку. Если через несколько недель вы все еще будете искать, загляните. Если хотите, напишите мне по электронной почте ( rex@stencilcms.com ).
Я слышал как положительные, так и отрицательные отзывы о Umbraco . Многим нравится Граффити , но оно больше ориентировано на блог, чем на полноценную CMS.
Моя компания только что завершила обзор нескольких коммерческих платформ CMS / порталов на основе .NET, и, хотя я не могу раскрыть, кто в них участвовал (спасибо, NDA!), Я могу вам сказать что IMO они все отстой очень и очень плохо.
Удачи в поисках. Я буду следить за этой веткой в надежде, что мы что-то упустили.
У нас был аналогичный набор требований, и мы выбрали Telerik Sitefinity . У него есть недостатки, но в целом я пока доволен.
К сожалению, Джеффри говорит правду. Наверное, поэтому каждые несколько лет я создаю новую пользовательскую CMS с нуля. По сути, мотивация для «коробочных» пакетов CMS состоит в том, чтобы иметь все возможности на земле и быть всем для всех и, следовательно, не делать ничего особенно хорошо для кого-либо. С раздуванием функций приходят кошмары юзабилити. Если только вы не начнете настраивать, а затем вы обычно заканчиваете разветвление проекта и теряете преимущество обновлений сообщества.
Kentico CMS согласно вашему списку:
Он основан на .net, .NET Framework 2.0 или более поздней версии
Доступна бесплатная версия, которую можно использовать в коммерческих целях, платная лицензия начинается с 750 долларов, исходный код является вариантом
Многие встроенные модули / функции, в любом случае их можно легко отключить, чтобы пользовательский интерфейс оставался простым в использовании
AD, Forms и Live Id! Интеграция
Поддержка UTF-8, включая языки RTL, совместимость с WAI, совместимость с XHTML, XML, XHTML, HTML, XSLT, CSS. http://www.kentico.com/Download.aspx