Какое знание архитектор программного обеспечения должен иметь о SharePoint?
Пожалуйста, попробуйте этот код, я думаю, что он отвечает на ваш вопрос
public virtual string BytesToString(byte[] bytes)
{
// code to convert a byte[] to a string.
return Convert.ToBase64String(bytes);
}
public virtual byte[] StringToObject(string ConvertThis)
{
// code to convert a string back to a byte[].
return Convert.FromBase64String(ConvertThis);
}
4 ответа
У архитектора должно быть вполне хорошее понимание нашего, продукт работает с функциональной и технической точки зрения.
Так, по-моему, архитектор должен:
- Были вовлечены по крайней мере в 2 Развертывания SharePoint, от дизайна до развертывания.
- Имейте знание нашего, главные sharepoint компоненты могут использоваться с помощью API. т.е. Сайты, Списки, Документы и компоненты Рабочего процесса.
Поскольку ни один из Ваших архитекторов не имеет это знание, я соединил бы их с экспертом Sharepoint в существующем проекте Sharepoint, таким образом, они получают знание, им нужно.
Sharepoint может быть противным зверем для работы с тем, если Вы не знаете входы и выходы его (они должны быть экспертами с ним для проектирования его). Как минимум они должны знать, как работают списки, сайты и полномочия. Идеально они должны также знать, как все веб-части совмещаются на страницах и как они, как предполагается, взаимодействуют. Действительно, если архитекторы не хотят узнавать о sharepoint, они собираются создать веб-приложение .NET и вынудить его работать на sharepoint. Это не будет действительно следовать за парадигмой того, как sharepoint приложение, как предполагается, работает.
Я посмотрел бы на компанию, названную Мышлением Sharp для руководства относительно того, что они должны изучить.
Навыки, такие как список, документы, рабочий процесс, полномочия... являются немного слишком основными и являются требованием для РАЗРАБОТЧИКА SharePoint.
Я утверждал бы, что, возможно, сайт (и структура сайта) является областью, которая подпала бы под пластину архитектора.
Существует больше областей, с которыми может помочь архитектор SharePoint:
Планирование мощностей - выполняющий несколько серверов в ферме. Масштабируемость и другие волшебные слова.
При знании возможностей и бизнес-сценариев использования SharePoint - это - очень общее.
Менеджер спрашивает: что SharePoint может сделать для меня? Разработчик спрашивает: хорошо, что Вы хотите, чтобы это сделало. Менеджер затем спрашивает: хорошо, я не знаю то, что это может сделать для меня поэтому, как я знаю то, что я хочу, чтобы это сделало?Тесно связанный с возможностями SharePoint различные затраты на лицензирование, связанные с каждым компонентом.
А также знакомство с разработкой и затратами на настройку. Займите то же время проекта, которое взяло бы в ASP.NET, затем умножает его на большой коэффициент и затем добавляет дополнительную константу.
И тесно связанный с what-can-it-do и how-much-does-it-cost, весь важный вопрос Возврата Инвестиций. Приветствую высший ROI!
Развертывание SharePoint может быть крупной проблемой и большим количеством боли.
Обновление SharePoint от v2 (MOSS 2003) к v3 (MOSS 2007). Мы должны видеть новую версию SharePoint в 2010 (?). Хорошо вскоре после того, как следующая версия Office идет наружу. Таким образом прошлые события обновления могут быть полезными.
Знание третьей стороны webparts. Я полагаю, что архитектор SharePoint должен смочь дать Вам по крайней мере 5 webparts, что они попробовали от CodePlex и говорят Вам, что они думают о них. Они свободны и легки захватить и играть на Вашем собственном досуге.
Некоторое знание коммерческого webparts. Поскольку они являются еще более дешевыми, чем запись Вашего собственного.
Имейте по крайней мере 5 блогов SharePoint, за которыми они следуют неукоснительно (знайте сообщество). Не имея их собственного блога SharePoint (отдают сообществу).
Если они находятся на StackOverflow, они должны попытаться ответить на вопросы SharePoint (такие как этот).
Посетите локальные группы пользователей SharePoint. Я думаю, что сообщества являются огромным соглашением. Особенно, что Вы узнали бы из разговора с людьми непосредственно и изучения, что они делают с их установкой SharePoint. Можно просто удивить себя.
Опыт с Интеграцией SharePoint - это прибывает в два одинаково важных аромата - оба от SharePoint, получающего доступ к существующим системам (бизнес-каталоги, webparts, и т.д.), а также другим системам, получающим доступ к содержанию SharePoint через веб-сервис или API.
Кроме того, SharePoint работает с (или работает хорошо) с Office, OCS, сообщая о сервисах, точке производительности, сервере проекта.
Расположения хостинга SharePoint - онлайн-сервисы Microsoft SharePoint могут быть популярной и более дешевой опцией начать использовать SharePoint. Это может быть размещено внутреннее, или со сторонней компанией. Знание опций всегда полезно.
Должно быть, прочитал код SharePoint с помощью отражателя (и предпочтительно все еще имея волосы).
Я думаю, что требуется по крайней мере несколько лет, чтобы быть архитектором SharePoint (Ваш пробег может отличаться). Вашим архитекторам.NET нужен к want-to-be архитектор SharePoint, иначе я соглашаюсь со сводками других передо мной - находят кого-то, кто уже архитектор SharePoint.
Мой совет - ищите деятеля, который не просто читает PowerPoint для многих в мире Sharepoint, просто основан на что говорили другие люди.
У нас возникли проблемы с сканированием 500000 элементов в ферме Sharepoint, и каждый рассказывает свою историю о том, как повысить скорость ... Обычно люди ссылаются не более чем на 2000 элементов в папке, но это не меняет скорость сканирования ...
Таким образом, хорошая архитектура - это тот, кто сам может сделать POC-подтверждение концепций своего дизайна, а не просто ссылаться на некоторые расплывчатые истории .....
У меня есть видел многих архитекторов Sharepoint, у которых не было опыта из реальной жизни ....