В SharePoint или нет (в качестве основы для разработки приложений) (по сравнению с ASP.NET)

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

1) Приложение использует документы, и эти документы нуждаются в какой-то функциональности, с которой SharePoint отлично справляется (поиск / индексирование, синхронизация с Outlook и т. Д.). Если все, что вам нужно, это корзина документов и список, тогда ASP.NET или ASP .NET MVC.

2) Приложение должно использовать рабочие процессы или настраиваемые рабочие процессы. Нет рабочего процесса, опять же, я бы посмотрел на ASP.NET или ASP.NET MVC.

3) Компания должна быть готова выделить для SharePoint как минимум 1 штатного разработчика. Не 1/2 или 1/3 проявителя. Чтобы правильно разрабатывать SharePoint, вам нужны приверженность и сосредоточенность. Вы должны выпить Kool-Aid. Если вы не хотите специализироваться на SharePoint, а хотите только попробовать, итоговые решения будут ужасными (ИМХО). Еще лучше, если вы можете выделить двух разработчиков или команду (подумайте о поддержке / обслуживании / опыте / специализации).

Так что ты думаешь?

примечание: я думаю, что все магазины Microsoft должны использовать готовые функции SharePoint, если их компания решила объединить их с Exchange в рамках своей архитектуры совместной работы. Я не против SharePoint.

ОБНОВЛЕНИЕ
Посидев на семинаре SP, я узнал, что рабочий процесс SharePoint применим только для отдельных элементов списка SharePoint. Поэтому, если в вашем рабочем процессе не используются элементы списка SharePoint, вам, вероятно, следует обратить внимание на .NET Workflow Foundation или что-то другое. Считайте это заменой моей позиции №2.


person MJLefevre    schedule 24.07.2009    source источник
comment
Я думаю, что отчасти проекты должны подходить для SharePoint именно из-за модели разработки. Например, развертывание кода в GAC и перезапуск пула приложений. Боль в шее на большом корпоративном сервере интрасети SharePoint.   -  person MJLefevre    schedule 30.07.2009


Ответы (4)


Я согласен. В настоящее время Sharepoint (moss 2007 / wss 3.0) делает пользовательскую разработку очень болезненным и медленным процессом. Единственное, с чем я не согласен, - это часть рабочего процесса. На мой взгляд, рабочий процесс в SharePoint практически неприменим, и его следует избегать. Если вы собираетесь выполнять рабочие процессы, выберите k2: blackpearl или MassTransit для бесплатного варианта с открытым исходным кодом.

person chris.w.mclean    schedule 24.07.2009
comment
Позвольте мне уточнить. Я не сказал, что рабочий процесс SP был отличным. Я просто имел в виду, что если в вашем приложении нет рабочего процесса, почему бы не использовать ASP.NET? Кстати, что случилось с Массовым Транзитом. Проект все еще очень активен? +1 к медленным и болезненным. - person MJLefevre; 24.07.2009
comment
Да, MassTransit все еще активен. Один из ведущих разработчиков этого проекта Крис Паттерсон находится здесь, в Талсе, и компания, в которой он работает, использует свои внутренние производственные системы, поэтому, даже если она не достигла версии 1.0, я думаю, что она довольно стабильна ... - person chris.w.mclean; 24.07.2009
comment
Теперь, надеюсь, MSFT исправит множество проблемных моментов разработчиков в 2010 году. У меня есть небольшая надежда, что создание пользовательских разработок в 2010 году будет гораздо более выгодным предложением. - person chris.w.mclean; 24.07.2009

Допустим, у вас есть хранилище данных, которое собирает данные из многих точек компании. Надеюсь, у вас есть несколько измерений, для которых бизнесмены назначены "владельцами измерений". Это люди, которые заинтересованы в организации данных в измерении. Они несут ответственность за поддержание в актуальном состоянии таких вещей, как иерархии и списки, но эти коллекции не заполняются данными об операциях, которые поступают из транзакционных систем, они представляют собой бизнес-термины, группы и описания, на которых говорит бизнес. Это их естественный деловой язык. Восточная группа продаж, малый бизнес, высокий риск, продвижение печатной рекламы 25 и т. Д. Дело в том, что ваше хранилище данных построено на 99% из операций / транзакций, но именно бизнес-механизмы делают все это разумным для ваших пользователей, и вам нужен место для его съемки.

Вы, безусловно, можете создать веб-приложение. Вы можете использовать файл Excel. Что бы ни. Но вы также можете использовать список SharePoint. SharePoint привлекателен для этого, когда среда уже существует (и, таким образом, ПОДДЕРЖИВАЕТСЯ), когда ваши требования не обширны, т. Е. Ссылочная целостность не требуется, у вас нет ресурсов для создания нового веб-приложения, бизнес-пользователи уже знакомы и удобны с SharePoint, он вам нужен вчера и т. д.

Поэтому я не говорю здесь о написании кода и компиляции библиотек для установки в SharePoint. Я просто пытаюсь представить разумное «подходящее время и место» для его использования.

Кстати - вот очень удобный инструкции по отправке и извлечению данных между списками SharePoint и SSIS.

person Eric Sabine    schedule 24.07.2009
comment
Я вижу, откуда вы. Но за 4 недели вы можете достаточно близко подойти к дублированию основных функций списков в SharePoint. И тогда у вас есть ПОЛНЫЙ контроль над приложением. Вам не нужно работать с абстракцией, которую вы не можете контролировать. Я надеюсь, что MS сделает что-нибудь, чтобы упростить получение данных из SP List. Если это основная часть стратегии Microsoft, получение данных должно быть таким же простым, как ODBC. +1 Хороший аргумент и ссылка - person MJLefevre; 24.07.2009
comment
При условии, что вы используете специальный инструмент, такой как MetaMan, использование SP в качестве средства выравнивания данных для корпоративных данных намного быстрее, чем создание собственного кода. Но вы действительно теряете контроль в модели SP. - person chris.w.mclean; 24.07.2009
comment
Потеряйте много контроля и $, используя BDC. Может быть, если бы BDC был бесплатным или стандартной частью SP, это было бы убедительнее. С другой стороны, нет смысла взимать плату за службы Excel (они не очень хороши). Мне действительно нравится, как поиск SharePoint работает с данными BDC. +1 к Microsoft по этому поводу. - person MJLefevre; 25.07.2009

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

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

person Nat    schedule 26.07.2009
comment
Думаю, это означает, что мы в некотором роде согласны. Мне нравится идея использовать его «из коробки», но для индивидуальной разработки вам действительно нужен эксперт и стратегия. - person MJLefevre; 28.07.2009
comment
+1 на хост-точку. Лично я большой поклонник iframe-модели разработки SharePoint. - person MJLefevre; 28.07.2009

Даже без документов вы все равно можете использовать Sharepoint в качестве платформы для портала с настраиваемыми веб-частями (возможно, некоторые из них основаны на библиотеках документов сайта). Это хорошая портальная платформа, и исследовательский портал моих компаний основан на sharepoint и работает довольно хорошо. Хорошо то, что с этим порталом sharepoint, основанным на веб-частях, вы все равно можете относительно легко решать проблемы с разрешениями и настройки презентации (перетаскивать веб-часть в определенную зону и т. Д., Что пользователи делают много, кстати). Кроме того, веб-части типа WSRP довольно хорошо работают с Sharepoint.

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

person Punit Vora    schedule 01.09.2009