Должны ли мы создавать наше веб-приложение следующего поколения на платформе DotNetNuke? - PullRequest
12 голосов
/ 10 февраля 2009

В настоящее время мы рассматриваем возможность использования DotNetNuke в качестве основы для нашего будущего настраиваемого на портале и настраиваемого клиентом веб-приложения, которое будет размещаться централизованно. Идея состоит в том, чтобы сделать динамические части в виде модулей DNN, которые, в свою очередь, взаимодействуют с внутренними WCF-сервисами, которые заботятся о бизнес-обработке и хранении данных.

Какие у вас хорошие / плохие впечатления от такой модели?

Что-нибудь, против чего вы бы предупредили или порекомендовали?

Любой совет будет оценен, спасибо ...

Ответы [ 7 ]

14 голосов
/ 11 февраля 2009

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

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

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

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

6 голосов
/ 10 февраля 2009

э-э-э, DNN? В самом деле?

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

5 голосов
/ 11 февраля 2009

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

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

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

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

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

2 голосов
/ 28 марта 2009

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

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

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

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

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

Недостатки

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

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

1 голос
/ 27 мая 2009

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

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

Моя жалоба на dotnetnuke состоит в том, что ее сложно выполнить модульным тестом.

0 голосов
/ 26 января 2019

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

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

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

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

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

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

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

0 голосов
/ 10 февраля 2009

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

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

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

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

...