Должны ли мы создать наше следующее поколение веб-приложений на платформе DotNetNuke?

Ответ 1

DotNetNuke может стать мощной платформой. Большинство людей, которые bash на самом деле не использовали его ни для чего, но просто знают, что он был создан давным-давно.

Я могу дать вам пару плюсов и минусов, чтобы посмотреть. Главным преимуществом использования его по сравнению с другими платформами CMS является то, что это очень зрелая платформа с довольно большим сообществом вокруг нее (например, Snowcovered). Для большинства задач он либо уже встроен, либо уже есть кто-то, кто создал модуль для этого. Его архитектура уже построена для поддержки кэширования и конфигурации фермы для приложений высокой доступности, что позволит устранить серьезную головную боль, если вы смотрите на большой объем запросов.

Однако место, где DotNetNuke может разочаровать, - это когда вам нужно делать многоэтапные процессы в своих модулях. Это, вероятно, верно для любой CMS, но вы почувствуете, что прыгаете через обручи, чтобы попытаться получить несколько отдельных модулей, чтобы дать "жесткий" пользовательский интерфейс. У меня на самом деле нет конкретного примера для этого - это просто ощущение, которое вы получаете от опыта, когда все находится в собственном "контейнере". Другое дело, что из коробки, он просто не имеет Web 2.0 смотреть на него. Вы можете настраивать скины и таблицы стилей, чтобы делать все, что угодно, но по какой-то причине это просто не было большим приоритетом для лагеря DNN в целом, как и для Drupal и других.

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

Ответ 2

eee, DNN? В самом деле?

Я открываю себя для пламени, но это продукт, который был создан для другого, менее цивилизованного возраста (VB.NET, бедная поддержка I18N, без msterpages). Более эффективные рамки существуют даже изначально в ASP.NET сейчас и лучше CMS в таких вещах, как Drupal. Я думаю, что это было очень хорошо, когда мы получили боль от ASP.NET 1.1, но я думаю, что ответ на ваш вопрос с названием "Нет" в наши дни.

Ответ 3

Я работал над несколькими проектами DNN. Есть несколько вещей, за которые я всегда застрял.

Первым делом и, возможно, самым важным является меню. Встроенные меню и приобретенные модули меню были очень ограниченными и сложными в использовании. Мы использовали преобразование xml для создания html для меню. Тем не менее, xml, который мы нам вернули, был плоским XML файлом. Не имеет смысла использовать иерархии, которые ограничивают некоторые из подменю, которые вы можете сделать. Таким образом, пункты меню уровня от 0 до 4 уровня были все братья и сестры друг друга.

Во-вторых, во многих модулях есть выбор. Если стандартный DNN не делает что-то, скорее всего, это модуль для него. Однако качество этих модулей сильно варьировалось от модуля к модулю.

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

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

Ответ 4

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

Преимущества

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

Рисунок гидратора, который DNN использует для создания объекта из БД, довольно гладкий и работает хорошо. Это также заставляет вас сохранять свои свойства объектов лаконичными с вашими sprocs/query, поэтому путаница сведена к минимуму.

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

Недостатки

Одна вещь, которую я заметил, и мы не смогли понять, почему, но DNN будет просто бросать ее скины время от времени. Там нет ошибок или очевидных причин. Он просто не применяет их и не будет делать этого до перезагрузки сервера.

Документация жестока. Если вы собираетесь использовать DNN, возьмите книгу. Это достаточно легко, без книги, но когда вам нужен справочный материал, можно найти NONE, что вообще полезно.

Ответ 5

Я работал над различными проектами dotnetnuke, масштабирующимися от простых блогов до полноценных создателей веб-сайтов (создания пользовательских дополнительных порталов).

Dotnetnuke отлично, как только вы узнаете, как это работает. Документации не хватает, но лучше.

Моя жалоба на dotnetnuke сводится к unit test.

Ответ 6

У меня нет опыта работы с Dot Net Nuke, но я посмотрел исходный код и рассмотрел использование ряда "систем управления контентом" "в качестве основы для веб-приложения.

Проблема с этим подходом заключается в том, что такие системы почти всегда имеют архитектуру, которая делает именно то, что вы хотите, достаточно болезненным. Библиотеки коммерческих классов предназначены в первую очередь для повторного использования (профессиональными компаниями), и они могут иметь свои проблемы. Система управления контентом даже не предназначена для повторного использования кода, даже если люди иногда пытаются это сделать. Легко найти кажущийся простой элемент (как составленный пример, скажем, строка, показывающая количество файлов) определяется и помещается на страницу очень удивительно. Это затрудняет изменение или удаление простых элементов - если вы можете узнать, как элемент помещается на страницу вообще! Помните также, что с этими приложениями вы также в некоторой степени зависимы от обновления и исправления ошибок коллектива, которые объединяют вещи. Uh, а также потому, что эти вещи являются общими, они, скорее всего, подвержены общему эксплойту (например, phpBB часто есть).

Я не смотрел Drupal. Он более современен и чаще используется в качестве основы для общего веб-портала. Но я все равно скептически отношусь к тому, чтобы использовать его в качестве основы того, что я сильно настраивал.

Если вы не собираетесь делать много изменений в первоначальной архитектуре DNN, я бы не хотел делать то, что вы предлагаете.

Ответ 7

Я использую его и выключаю с момента его бета-тестирования почти два десятилетия назад, и, вероятно, я потратил 10 тысяч часов своего времени на создание веб-сайтов и веб-приложений на базе DNN. Вот мое взятие...

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

Чтобы ответить на прямой вопрос OP, это не страшное решение для построения, если и только если модули, которые ваше здание не нуждается во взаимодействии с ядром DNN и не ориентированы на управление контентом. Это может быть хорошо для обычного портала для клиентов, где вы хотите, чтобы пользователи могли войти в систему, получить доступ к некоторой информации или ресурсам и т.д.

Тем не менее, существуют некоторые ОСНОВНЫЕ недостатки системы DNN, о которых вам следует знать. Я любил это. Сейчас я бы даже не подумал использовать его для проекта с нуля.

Вот только некоторые из проблем с DNN:

1. DotNetNuke в НЕ истинной CMS! С ним нельзя управлять типами контента, не добавляя дорогой сторонний модуль.
2. Практически невозможно настроить интерфейс администратора в соответствии с вашими требованиями или улучшить описанный ниже пользовательский интерфейс.
3. Нулевые инновации - DNN на несколько лет позади других CMS, таких как Drupal и Wordpress. Они не делали ничего инновационного с этим продуктом с первых лет его существования в начале 2000-х годов.
4. Он остается неполированным и неисправным, команда DNN, кажется, постоянно изобретает колесо, изменяя вещи ради их изменения.
5. Он построен на очень устаревших технологиях веб-форм и не планирует оживлять его ядро.
6. Это становится все более и более коммерциализированным и все менее открытым исходным кодом. Нет особого чувства общности, которое вы найдете распространенным во многих других проектах с открытым исходным кодом.

У меня есть полное, более подробное описание недостатков DNN здесь, в моем блоге. НТН