요즘에는 많은 셰어 포인트 개발을 시작하고 있으며 일부는 내가 한 일이고 pagelayouts, 목록 정의, 마스터 페이지 등과 같은 것들에 대해 셰어 포인트 디자이너를 직접 사용하는 것입니다. 저의 관점에서 보기의 그 Visual Studio에서 모든 일을 더 조직 생각합니다. 그렇게하면 각 솔루션을 소스 제어 데이터베이스에 연결하고 스크립트를 사용하여 배포/취소/업그레이드를보다 쉽게 수행 할 수 있습니다.쉐어 포인트 개발을 어떻게 구성합니까?
내 아이디어는 다음과 같은 vs 솔루션을 만드는 것입니다. 1. 목록 및 콘텐츠 유형 정의를위한 것. 2. 웹 파트 용. 3. 상표를 붙이기위한 것
그러나이 접근법에는 어떤 단점이 있습니까, 다른 접근법을 사용하고 있습니까?
실제 답변은 다음과 같습니다.
Visual Studio 솔루션 또는 SharePoint 솔루션 패키지를 구성하는 가장 좋은 방법은 없을 것이라고 생각합니다. 결국, 당신은 당신의 조직에 가장 잘 맞는 것을 찾아야합니다.
내가 본 유일한 지침은 SharePoint 온라인 문서에서입니다 :
개발 팀이 10 개 이상의 WSP 파일을 필요로하는 솔루션을 설계하는 경우, 팀은 아키텍처를 재고해야한다. 단일 배포 창 내에서 너무 많은 WSP 파일을 관리하고 배포하기가 어렵고 솔루션을 관리 할 때 SharePoint Online의 복잡성으로 인해 솔루션의 거부가 발생할 수 있습니다.
많은 수의 솔루션 패키지 (WSP 파일)를 추적하고 관리해야 배포 할 수 있습니다. 사용자 지정에서 솔루션 패키지가 많을수록 무언가가 제대로 설치되지 않을 가능성이 커지고 솔루션을 배포하는 데 오래 오래 걸릴 수 있으며 호환되지 않는 버전의 솔루션 패키지를 쉽게 혼합 할 수 있습니다. 고객은 배포 계획을 면밀히 조사하고 솔루션 패키지 수를 프로젝트에 필요한 최소 수로 유지하는 것이 좋습니다. 솔루션 패키지에는 여러 기능이 포함될 수 있으므로 각 기능에 대해 하나의 솔루션 패키지를 가질 필요가 없습니다.
그리고 저는 이것에 동의합니다. 하나의 SharePoint 솔루션 패키지에서 실제로 3 가지 기능을 제공하는 3 가지 Visual Studio 솔루션 및/또는 SharePoint 솔루션 패키지의 윤곽을 그리는 것처럼 보입니다.
각 프로젝트마다 하나의 Visual Studio 솔루션을 만드는 경향이 있습니다. 매우 큰 프로젝트의 경우 단일 Visual Studio 솔루션에는 각각 SharePoint 솔루션 패키지를 나타내는 여러 프로젝트가 포함될 수 있습니다.
팜 솔루션의 경우 각 SharePoint 솔루션 패키지에는 기능 또는 응용 프로그램과 관련된 많은 기능 및 파일이 포함됩니다. 둘 이상의 SharePoint 솔루션 패키지가 공통 기능을 공유하는 경우 이러한 공유 기능을 별도의 솔루션 패키지에 포함합니다.
샌드 박스 솔루션은 팜 솔루션보다 훨씬 작은 경향이 있습니다. 팜 솔루션은 대개 응용 프로그램을 나타내지 만 샌드 박스 솔루션은 특정 문제를 해결하는 데 더 집중합니다. 따라서 샌드 박스 솔루션에는 일반적으로 다른 맞춤 기능이나 솔루션에 의존하지 않는 기능이 하나만 포함되어 있습니다.
처음에 말했듯이, 나는 단단하고 빠른 규칙이 있다고 생각하지 않습니다. 일반적으로 특정 개발 팀의 선호도 및 스타일에 따라 결정됩니다.처음에는 몇 가지 방법을 시도해보십시오. 그러면 결국 팀에 가장 적합한 것을 찾을 수 있습니다.