У меня есть клиент, которому нужно создать сложный сайт интрасети, управляемый рабочими процессами / формами, с несколькими ролями и около 20 рабочими процессами, функциями управления документами и уведомлениями по электронной почте / факсу.
Какая платформа подходит для такого сайта?
Подходит ли для этого SharePoint Foundation 2010, или я могу использовать SharePoint Server Enterprise? В качестве альтернативы есть что-то еще, что отвечает всем требованиям?
Подходящая платформа во многом будет зависеть от конкретных потребностей клиента. Я потратил последние пару лет на разработку веб-приложения, управляемого рабочими процессами / формами, на ASP.NET. Это сработало очень хорошо, особенно после того, как мы начали переходить на ASP.NET MVC. У нас есть демографический контроль доступа на основе ролей, демографические макеты порталов, правила и уведомления по электронной почте. Теперь у нас, вероятно, есть полдюжины рабочих процессов, настроенных для нескольких разных клиентов, и теперь, когда инфраструктура создана, создание новых рабочих процессов и перенастройка существующих можно выполнять почти полностью из пользовательского интерфейса администратора.
В .NET Framework теперь есть платформа Workflow Foundation, но мы решили, что наши потребности не очень хорошо совпадают с ее набором функций. С несколькими хорошими разработчиками ASP.NET MVC и Entity Framework предоставляют нам все необходимые функции.
теперь я просто догадываюсь, потому что это звучит не сильно отличается от обычных требований настройки портала, но, возможно, кому-то это пригодится
Я только что открыл решение, которое использует IronPython в SharePoint - приемник событий со сценариями, задание таймера, страницу, рабочий процесс, консоль - и позволяет легко развертывать, сохранять, редактировать и настраивать сценарии в одном месте - https://github.com/kerray/NAVERTICA-SPTools
отчасти это натянуто, в настоящее время он не такой гибкий в отделе рабочего процесса, и это никоим образом не отточенный продукт, но его можно довольно легко расширить
Основное преимущество этого, помимо сохранения рассудка при столкновении с SharePoint API, заключается в том, что он позволяет нам реализовывать решения, которые сильно настраиваются, и при этом вся кодовая база состоит из одного общего решения - настройки выполняются при реализации с использованием Скрипты IronPython
есть также некоторые другие потенциально интересные вещи в C # для тех, кто хочет покопаться (или готов подождать, пока я не закончу хотя бы общий обзор)
и хотя мне было разрешено открывать исходный код только довольно ограниченную часть того, что мы в противном случае используем для создания настраиваемых порталов для наших клиентов, я помню, как начинал с SharePoint, и я знаю, что убил бы за такие инструменты (не то чтобы они идеальны для всех, но все же)
и не забывайте, он на 100% работает только с SharePoint Foundation 2010
Вы можете использовать SharePoint Foundation 2010 для размещения Windows Workflow Foundation (http://msdn.microsoft.com/en-us/library/ms414613.aspx).
Windows Workflow Foundation, размещенная на SP Foundation 2010, довольно надежна и, на мой взгляд, хорошо соответствует вашим требованиям.
Вы можете посмотреть на некоторые коммерческие платформы, такие как Iceberg, который сочетает в себе инструменты пользовательского интерфейса с конструктором рабочего процесса с указанием и щелчком и является на основе .net
