SharePoint 2010 - 모범 사례:어셈블리를 처리하는 방법 [토론]

Question

SharePoint용으로 프로그래밍할 때 수년 동안 진행되어 온 논의가 있습니다.

Visual Studio에서는 배포하기 위해 .wsp 파일로 변환되는 SharePoint 솔루션을 추가할 수 있습니다.이 .wsp 파일에는 필요한 모든 어셈블리 파일이 포함됩니다.

다음을 위해 코드 숨김 파일을 어떻게 처리합니까?이벤트 수신기, 기능 수신기, aspx 페이지?

이 .cs 파일을 SharePoint 폴더에 저장하시나요?(이 방법으로 SharePoint 프로젝트에서도 .dll을 배포해야 합니다)

아니면 모든 코드 로직을 하나 이상의 다른 프로젝트(클래스 라이브러리)로 이동합니까?

예를 들어 두 번째 예에서 수행하는 작업은 다음과 같습니다.

• 마우스 오른쪽 버튼 클릭, 새 항목 추가, 이벤트 수신기
• .cs 파일을 다른 프로젝트로 이동
• Elements.xml 파일 내의 어셈블리 정보 변경

첫 번째 예에서는 이러한 파일을 이동하지 않고 VS2010이 추가할 때 그대로 유지합니다.

나는 어떤 방식을 선호하는지 말하는 것이 아니라 단지 많은 의견을 듣고 싶을 뿐입니다."옵션 2는 나쁘다"고 말하지 마십시오. 나는 왜 그런지, 왜 그렇지 않은지 알고 싶습니다!

감사해요

편집하다:

여기서 내 질문은 확장 기능 등과 관련이 없습니다.

나는 귀하의 SharePoint 솔루션에 .cs 파일이 포함되어 있지 않은지 확인하는 것에 대해 이야기하고 있습니다.이렇게 하면 이 솔루션을 위해 GAC에 어셈블리가 있을 필요가 없습니다.

예:Customer.SPS.Intranet.Solution(=WSP를 생성하는 솔루션이므로 빈 SharePoint 프로젝트 항목)이 있습니다.

단순히 기능과 기능 수신기를 추가하면 .cs 파일이 생성되고 (배포 후) Customer.SPS.Intranet.Solution.dll 파일이 전역 어셈블리 캐시 내에 배치됩니다.

이것은 어떤 사람들이 갖고 싶어하지 않는 것입니다 !!!(이유를 모르겠어서 의견을 여쭤봅니다.)

이 문제를 해결하기 위해 이 솔루션 내에 다음과 같은 이름의 프로젝트를 만듭니다."Customer.SPS.Intranet.Logic", 이 솔루션에는 모든 기능 수신기 코드 숨김 파일이 포함됩니다.

이는 "Logic" 프로젝트에 있는 수신기 클래스를 사용하려면 기능 template.xml 파일을 편집해야 함을 의미합니다.이렇게 하면 "Customer.SPS.Intranet.Solution"을 깨끗하게 유지하고 패키징에만 사용할 것입니다.따라서 "Customer.SPS.Intranet.Solution.dll"이라는 이름의 GAC에 배포된 어셈블리는 없을 것입니다...대신 Customer.SPS.Intranet.Logic.dll 어셈블리가 GAC에 배포됩니다.

Answer 1

아아, 솔루션과 DLL의 영원한 질문입니다.:-) 왜 헤어져야 하고, 왜 안 되고, 언제 헤어져야 할까요?저는 현재 근무 중이 아니며 휴가 중입니다. 하지만 한 번 살펴보라고 하셔서 몇 가지 테이크아웃 항목과 이에 대한 의견을 요약하겠습니다.그래서 내 대답은 개인적인 경험과 견해를 바탕으로 한 것입니다.(죄송합니다 StackExchange)

x  '코드 숨김'과 UI를 분리하지 않으면 코드를 유지 관리하기 어려워집니다.다른 프로젝트에서 제가 본 것은 경험이 부족한 개발자가 "코드 숨김"(XML/ASPX 옆에 있는 C# 클래스)에 잘 대처하지 못한다는 것입니다. 그들은 UI에 직접 액세스할 수 있기 때문에 코드 뒤에 더 많은 논리를 작성하는 경향이 있습니다.한 특정 프로젝트에서 나는 1500줄(이미 엄청난 양)의 "새" 페이지를 보았고 "편집" 페이지는 기본적으로 새 페이지를 복사하여 붙여넣은 것이었습니다.물론 이것은 '나쁜 프로그래밍'입니다.  아티팩트 옆에 코드를 배치하는 것이 본질적인 것은 아닙니다.그러나 나쁜 습관은 바꾸기 어렵고 이러한 작업 모델은 상황을 더욱 악화시키는 데 도움이 될 수 있습니다.이 경우 cs 클래스를 먼저 컨트롤로 만들고 편집 클래스에 대해 일종의 상속 클래스를 갖는 것이 유지 관리가 더 쉬웠을 것입니다.일단 생성되면 asps 페이지가 이러한 클래스에서 상속되도록 할 수 있습니다.

x "코드 숨김"을 분리하지 않으면 UI가 너무 많은 논리를 포함하는 클래스로 이어집니다.해당 프로젝트의 또 다른 점은 편집 페이지인 새 페이지가 모두 외부 SQL 데이터베이스에 직접 연결되어 있다는 것입니다.그들은 코드 및 유지 관리에 오버헤드를 발생시키는 직접 SQL 연결을 사용했습니다.계층화된 접근 방식이 큰 도움이 되었을 것입니다.

x 계층화된 애플리케이션에는 별도의 어셈블리가 필요합니다.뭐, 레이어링도 굿!별도의 조립이 필요한가요?반드시 그런 것은 아닙니다.어셈블리 내의 별도 폴더/네임스페이스에 논리, 데이터 액세스 계층 등을 그룹화할 수 있습니다.그것들도 레이어입니다."하지만 왜 내가 그들을 분할해야합니까?" 그것은 좋은 연습 경향이 있습니다.왜?더 깊은 로직(예: SQL 연결)을 실수로 사용하는 것을 방지할 수 있습니다. 해당 로직은 DA 레이어에서만 참조되기 때문입니다.또 다른 장점은 최상위 레이어를 다른 레이어로 교체하는 것이 잠재적으로 더 쉽다는 것입니다.다른 사용자 인터페이스나 모바일 인터페이스를 말해보세요.더 나아가 하위 레이어를 보다 일반적으로 만들 수 있으므로 나중에 다시 사용할 수 있습니다.이것이 nHibernate 및 EF 프레임워크가 생성될 수 있는 방법입니다.

X "멋지지만 ASP.NET 개발 일뿐입니다." 맞지만 수신기와 같은 SharePoint 아티팩트를 개발할 때 동일한 원칙과 아이디어를 사용할 수 있습니다.기능 속성이나 폴더 속성으로 매개변수화할 수 있는 일반 수신기로 작업해 보는 것은 어떨까요?로직을 재사용하면 대부분 더 안정적인 솔루션이 생성됩니다.

x 분리는 (단위)테스트를 장려합니다.좀 더 일반적인 클래스 등을 분리하고 생성하기 시작하면 인터페이스와 모델을 사용하는 데 더 이상 오랜 시간이 걸리지 않습니다.즉, 더 쉽게 모의할 수 있으므로 단위 테스트를 구현하기가 더 쉬울 것입니다(실제로는 TDD를 사용해야 하지만).MVC 프레임워크를 살펴보고 프레임워크가 어떻게 훌륭하게 구분되어 있는지 살펴보세요.이는 SharePoint에서도 작동합니다.

따라서 내 2c(및 변경 사항 ;-))를 요약하면  아티팩트에 직접 조인 뒤의 코드를 사용할 수 있지만 저는 그렇게 하지 않는 것을 선호합니다.나는 자동 일치 수신기와 아티팩트에 대한 코드를 갖는 것보다 재사용되고 일반적이며 테스트 가능한 코드를 선호합니다(단, 속성에 기능 수신기를 추가하기 때문에 수동 사례에서는 기능 템플릿 XML을 변경할 필요가 없지만). 찾기 쉬움(저는 VS2010의 인스턴트 Go To를 사용합니다) 그러나 결국 그것은 귀하와 귀하의 프로젝트가 선호하는 것에 관한 것입니다.:-)

Answer 2

실제로 개인적으로 재사용 가능한 부분을 식별한 상황을 제외하고는 SharePoint 솔루션의 파일이 프로젝트 외부로 이동되는 솔루션을 본 적이 없습니다.예를 들어확장 메서드, 기본 이벤트 처리기 코드.이동하지 않는 이유도 있습니다.일반적으로 VS 2010은 내부 작업을 위해 클래스가 장식된 GUID를 사용하여 핸들러를 연결하므로 종속성을 올바르게 구축할 수 있습니다.또한 모든 바이너리는 어쨌든 내장되어 있으므로 코드 비사이드(SP2010에서는 더 이상 코드 비하인드가 없음)가 이미 내장되어 있습니다.SafeControls(웹 파트, 사용자 지정 컨트롤 등)을 등록하는 것 외에도 Visual Studio가 외부 어셈블리를 패키지에 포함할 수 있으므로 제대로 등록되지 않지만 실제 코드를 위해 해당 어셈블리를 반드시 스카우트할 필요는 없습니다. 모든 작업을 수행해야 합니다. 수동으로 - 생산성이 좋지 않습니다.

이는 초기 반영이며 더 많은 내용이 포함될 수 있지만 기본 규칙은 다음과 같습니다.해당 부분을 재사용하지 않는 것이 좋습니다. 그러면 VS가 제안하는 곳에 두는 것이 좋습니다.오히려 배포할 기능의 종류, 종속성, 기능 범위, 활성화 순서 등을 미리 계획하세요.

도움이되기를 바랍니다. c : marius