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

У меня есть POV, что вы должны использовать SharePoint для разработки приложений в этих условиях.В SharePoint или нет (в качестве основы для разработки приложений) (vs ASP.NET)

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, но только готовы к ошибкам, результирующие решения ужасны (IMHO). Еще лучше, если вы можете посвятить двух разработчиков или команду (подумайте о поддержке/обслуживании/экспертизе/специализации).

Как вы думаете?

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

UPDATE
Посидев в мастерской П. я узнал, что SharePoint Workflow применима только для каждого элемента списка SharePoint основе. Поэтому, если ваш рабочий процесс не использует элементы списка SharePoint, вам следует, вероятно, взглянуть на фундамент .NET Workflow или что-то свое. Рассмотрите эту замену моему элементу № 2.

источник

2009-07-24 MJLefevre

+1 Слушайте, слышите !!! –

Я думаю, что часть части проекта должна быть подходящей для SharePoint - это модель разработки. Например, развертывание кода в GAC и перезапуск пула приложений. Боль в шее на большом корпоративном сервере интрасети SharePoint. – MJLefevre

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

источник

2009-07-24 14:22:53

Позвольте пояснить. Я не говорил, что рабочий процесс SP был отличным. Я просто имел в виду, что если ваше приложение не имеет рабочего процесса, почему бы не использовать ASP.NET? Кстати, что случилось с Mass Transit. Является ли проект еще очень активным? +1 на медленном и болезненном. – MJLefevre

Да, MassTransit все еще активен. Один из ведущих разработчиков этого Криса Паттерсона находится здесь, в Талсе, и компания, которую он работает для использования в своих внутренних производственных системах, поэтому, даже если он не ударил v1.0, я думаю, что это довольно стабильно ... –

Теперь, надеюсь, MSFT в 2010 году исправит множество болевых точек dev. У меня есть небольшая надежда, что выполнение пользовательских dev в 2010 году будет гораздо более выгодным предложением. –

Предположим, у вас есть хранилище данных, которое собирает данные из многих точек в компании. Надеюсь, у вас есть несколько измерений, которые бизнесмены называют «владельцами измерений». Это люди, которые заинтересованы в организации данных в измерении. Они несут ответственность за сохранение таких вещей, как иерархии и списки, но эти коллекции не заполнены данными операций, которые поступают из транзакционных систем, это бизнес-термины и группы и описания, которые говорит бизнес. Это их естественный деловой язык. East Sales Team, Small Business, High Risk, Print-Ad Promotion 25 и т. Д. Дело в том, что ваш хранилище данных построено из 99% операций/транзакционных материалов, но это деловые отношения, которые делают все это разумным для ваших пользователей, и вам нужно место для его захвата.

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

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

BTW - Здесь очень удобно how-to on pushing and pulling data between SharePoint lists and SSIS.

источник

2009-07-24 15:21:31

Я вижу, откуда вы. Но через 4 недели вы можете приблизиться к дублированию основных функций списка в SharePoint. И тогда у вас есть TOTAL контроль над приложением. Вам не нужно работать с абстракцией, которую вы не контролируете. Я надеюсь, что MS сделает что-то, чтобы облегчить получение данных из списка SP. Если это ключевая часть стратегии Microsoft, получение данных должно быть таким же простым, как ODBC. +1 Хороший аргумент и ссылка – MJLefevre

При использовании специального инструмента, такого как MetaMan, использование SP в качестве поверхностного носителя данных для ваших корпоративных данных намного быстрее, чем его собственное кодирование. Но вы теряете много контроля в модели SP. –

Потеряйте много контроля и $ используя BDC. Возможно, если бы BDC был бесплатной или стандартной частью SP, это было бы более убедительным. По касательной, это не имеет смысла взимать плату за Службы Excel (они не очень хорошие). Мне действительно нравится, как поиск SharePoint работает над данными BDC. +1 к Microsoft по этому поводу. – MJLefevre

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

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

источник

2009-07-26 07:30:59 Nat

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

+1 на хост-точке. Лично я большой поклонник «iframe-модели» разработки SharePoint. – MJLefevre

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

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

источник

2009-09-01 15:31:22 desigeek

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

ответ

Смежные вопросы