Microsoft 응용 프로그램 블록에 대한 귀하의 경험은 무엇입니까

Question

Microsoft 응용 프로그램 블록 및 기타 Microsoft 솔루션에 대한 귀하의 실제 경험은 귀하의 솔루션을 작성하는 것과 반대되는 점이 무엇입니까?

나는 새 프로젝트를 시작했고 그들에게 한발 더 나아 가기로 결정했다. 예외 처리 및 로깅 블록을 사용했습니다. 예외 처리 블록은 필자가 필요로하는 부분에 적합합니다. 로깅 블록은 필자가 필요로하는 것의 95 %를 차지했고 나머지는 사용자 정의해야했습니다. 그것을 커스터마이징하는 방법을 배우는데 시간이 걸렸고 버전 참조 문제가있었습니다. 로깅은 파일이나 데이터베이스 (이 프로젝트에서 모두)에 이르기까지 매우 간단한 작업입니다. 뒤늦은 지쳐서 내 자신의 글을 쓰는 것이 더 빠를 것입니다.

또한 프로젝트는 PDA와 데이터를 동기화해야합니다. 약간의 연구를 통해 Microsoft가 지적한 방향이 동기화 서비스 였음이 분명해 보였습니다. 약 3 일 동안 다른 소프트웨어의 모든 올바른 버전을 얻으려고 시도한 후에 나는 샘플을 작동시키지 못했습니다. Windows Mobile Synchronization Error. 필자는 간단한 OpenNETCF Desktop Communication을 사용하여 PDA에서 /로 파일을 복사하고, 이진 객체 직렬화를 사용하고, 시간을 덜 들여 원하는 방식으로 모든 작업을 수행하는 자체 기본 동기화 코드를 작성했습니다. 좋은 :))

일부 긍정적 :

• 휠을 업데이트에서
• 혜택을 재발견 할 필요가 없습니다
그들과 함께
• 큰 사용자 기반이 증가하도록 설계 다른 도구에서
• 혜택 피드백, 테스트 및 강력한
  • 오버 : 좋은
  • 이력서에 가지고 다움은
  새로운 개발자가 그들에 익숙 할 수있는 팀에 추가
  • 은 사용자 정의 기능의 많은

  네거티브를 제공합니다 스위스 군용 칼이되도록 노력하고 복잡성을 야기하는 한 가지 솔루션에 필요한 것보다 훨씬 더 많은 기능을 제공합니다.

• 그럼에도 불구하고 그들은 프로젝트의 모든 요구 사항을 충족시키지 못하는 것 같습니다. 꼬리는 개를 휘두르는 결과를 가져올 수 있습니다. 나는 이것이 애플리케이션의 작동 방식에 얼마나 많은 영향을 미치는지에 달려 있다고 생각합니다.
• 응용 프로그램 블록을 올바르게 구현하는 방법을 알아야합니다. (확인해봤을 때 처음 사용했을 때만 사용하면됩니다.)
• 다른 DLL 버전에 대한 의존도가 증가합니다. 사용자 정의하기 어려운
• 인해 복잡성이
• 크고 성가신 (정말 문제가 요즘)와

이 내 학습 경험이었다 및 수 나를 더 나은 결정을 내릴 장착 할 수 있습니다 Microsoft 솔루션 (또는 다른 제 3 자 lutions) 대 내 자신의 글쓰기.

귀하의 경험은 어떻습니까?

Answer 1

이들은 모두 입니다.이 번호는이며, 그게 내 가장 큰 문제였습니다. 결국에는 제거하고 더 이상 사용하지 않습니다.

이들은 충분히 유용하지 않고 시스템에서 너무 많은 구성, 수정이 필요하며 변경 사항이 계속 유지됩니다. 단순히 로깅 기능을 추가하려면 2 일을 마치기 만하면 끝납니다.

예상되는대로 10 분 안에 작동하는 라이브러리가 있습니다.

Answer 2

실제로 응용 프로그램 블록을 실제로 사용하지는 않았지만 설명서를 읽고 예제를 살펴 보았습니다.필자가 생각하기에, 뭔가 빨리 끝내야 할 때 좋은 자료가 될 수도 있지만 그렇지 않은 경우 Microsoft가 원하는 방식으로 작동하지 않는 업데이트를 출시 할 때 자신을 되돌릴 수있는 좋은 방법입니다.

필자는 로깅 및 예외 처리 기능을 자체적으로 작성하는 것이 좋습니다. 그렇게하면 응용 프로그램의 필요에 따라 추가 및 제거되는 항목이 결정됩니다. 바퀴를 재발 명하는 것에 관해서는, 그것은 그렇게 많이 나를 괴롭히지 않는다. 차라리 해킹해야하는 일반 프로그래밍 공동체의 사양에 맞게 제작 된 것을 사용하는 것이 아니라 사양에 맞춰 제작할 것입니다.

Answer 3

나는 더 많은 것을 사용했기 때문에 더 많이 사용하지 않았기 때문에 나는 그것을 많이 사용하지 않았다. 예를 들어, 예외를 처리 할 때 나는 CodePlex.Diagnostics (SQL Server에서 물건을 로깅하는 멋진 패키지)를 사용했다. 매우 간단하고 웹 응용 프로그램에 유용합니다. 로깅을 위해 Log4PostSharp의 제어하에 log4net을 사용합니다. 물론 프리 컴파일이 정의 상으로 동적 프록시보다 빠르기 때문에 PIAB 대신 PostSharp를 사용합니다.

하나의 멋진 점은 Unity 응용 프로그램 블록입니다. 다른 DI 프레임 워크에서 습득 한 교훈을 마음에 새기고 실제로 사용하기 쉽습니다 (물론 PostSharp4Unity도 있습니다).

Answer 4

데이터 액세스 및 예외 처리 블록 (내가 사용한 2 개)은 기본 기능 이외의 기능을 즉시 찾고 있지 않은 경우 우수합니다. 다른 강력한 프레임 워크가 있지만 최소한의 구성과 매우 얕은 학습 곡선으로이 두 블록을 빠르게 가동 할 수 있습니다.

팩토리 패턴을 사용하기 때문에 필요에 따라 쉽게 확장 할 수 있습니다. 예외 처리 블록을 사용자 지정하여 모든 종류의 Active Directory 데이터와 Exception이 표시되도록했습니다. 괜찮은 덩어리로 우리의 지원 시간을 줄였습니다.

Answer 5

유지 관리 응용 프로그램이 있습니까? AB (또는 그 밖의 다른 구성 요소)가 당신을 도울 수 있는지, 테스트했는지, 그리고 그들이 소집을 통과하면 사용할지, 그렇지 않으면 사용하는지 확인하십시오.

유지 관리를 위해이 많고 커지는 이 있습니까? 그런 다음 동일한 종류의 코드를 작성하여 예를 들어 로깅, 인증 & 인증, 원격 통신 및 이와 유사한 되풀이 문제 (비즈니스 및 IT 환경에 따라 정확하게 달라질 수 있음) 문제를 해결하기 위해 자신의 코드 나 구성 요소를 옮기십시오 (그리고 유지하십시오!). 또는 선반에서 무언가를 사용하십시오. 일반적으로 이러한 방법 중 하나 (항상 그렇지는 않더라도)는 많은 수의 응용 프로그램과 회사 내에서의 업무 순환을 통해 더 잘 작동하는 경향이 있습니다. 어느 것 같아요! (특히, 새로운 개발자/관리자가 2 년 이상의 응용 프로그램에서 생산적이되도록 훈련 시간을 과소 평가하지 마십시오. 이전에 작업 한 다른 구성 요소와 유사하거나 공유 된 구성 요소가 없습니다.)

MS 응용 프로그램 블록 중 몇 년 전이었습니다.당시 예외 처리 블록과 데이터베이스 액세스 블록은 많은 도움이되었습니다. 로깅 AB는 합리적으로 훌륭했습니다 (그래도 내가 세밀한 제어를 위해 log4net을 선호했습니다). 현재 AB의 대부분은 거기에 없었습니다. 내 생각에 현재 프레임 워크에서 AB의 주소 단점은 입니다. 성공한 경우 (그리고 기존의 문제점을 실제로 해결 한 경우) 향후 프레임 워크 버전으로 이전하거나 언어 및/또는 프레임 워크를 확장하여 고통 지점을 직접 해결할 수 있다고 생각해야합니다.

코드는 특정 목적으로 만 지나치게 또는 저급 적으로 설계되지 않습니다. 기성품을 평가하는 것의 큰 과제는 시장 말하기 또는 지나치게 낙관적 인 세계 및 부엌 싱크대 선언에 반대되는 의미에서 실제로 그 목적이 무엇인지 찾아내는 것입니다. MS의 P&P group은 제품 개발 팀에서 멀리 떨어져있는 것으로 보이며 최근 제품 버전에 대한 통찰력이 부족한 occasionally address the wrong problems ...

Answer 6

.NET 1.1/early .NET 2.0부터 사용하지 않았으며 매우 제한적이었습니다. 데이터 용 응용 프로그램 블록. 솔직히 말해서 나는 최근에 어떤 것을 사용하는 것을 고려하지 않았고, 나는 그들이 현재 가지고있는 것을보고보아야 만합니다.

나를 위해 실제로 내 자신의 솔루션을 작성하는 것이 쉬워졌습니다. 일반적으로 나는 꽤 특별한 경우가있어서, 내가 원하는 방식대로 일하도록 몇 가지 농구를 뛰어 넘어야했다. 그런 다음 다시 ASP.NET 작업을 수행하고 있었고 (일반적으로 웹 개발과 관련하여 많은 사람들이있는 것처럼 보입니다) 이제 대부분 Windows 응용 프로그램으로 바뀌 었습니다.

나는 이것이 사례별로 필요한 것이라고 생각합니다. 그것이 당신을 위해 작동하고 당신의 필요를 충족 시키면 거기있는 것을 사용하십시오. 완벽하게 실행 가능한 솔루션이있을 때 뭔가를 다시 만드는 데 시간을 낭비 할 필요가 없습니다. 또한 DLL의 새 버전을 릴리스하면 프레임 워크 버전 등을 변경하지 않으면 업데이트해야 할 이유가 없습니다. 어차피 내 경험으로.

Answer 7

우리는 Unity를 약간의 성공으로 사용하고 있습니다. 나는 일반적으로 DI 컨테이너에 반대하지만, 하나를 사용해야 할 경우 Unity는 충분히 잘 작동합니다.

나는 다른 사람들의 대부분에 대해 덜 확신합니다. 로깅 라이브러리는 특히 나를 괴롭혔습니다. 거대하고 힘이 들며 특정 (단순화 된) 시나리오에 하드 코딩 되었기 때문에 바보 같은 양의 코드를 다시 구현하여 라이브러리를 실제로 명백한 기능으로 확장해야합니다. 그리고 문서는 절대적인 기본 사항을 넘어선 사용자 정의 및 구성 방법에 대해 개략적입니다.

데이터 액세스 블록에서도별로 도움이되지 않습니다.

전체적으로 나는 큰 팬이 아닙니다.

Answer 8

로깅, 예외 처리 및 유효성 검사 블록을 사용하고 있습니다.

로깅 AB에 대한 나의 경험은 당신과 비슷했다 : 당신에게 거기에 오는 길의 95 %를 가져다 준다. 커스터마이징은 쉽지 않으며 모든 종류의 오버 헤드 (업데이트, 알 수없는 영역에서의 테스트, ..). 전반적으로, 필자는 구성 옵션이 매우 편리하기 때문에 (특히 개발 중에 그리 많지는 않지만, 배포 할 때 편집기를 사용하고 켜기/끄기를하는 것이 좋습니다.) 런타임시 필터 등). 우리가 필요로하는 것보다 더 많은 옵션을 제공한다는 것을 알았을 때 (예 : 별도의 심각도/우선 순위 - 다시 차이점은 무엇입니까?) 등의 작은 래퍼를 작성했습니다.

우리는 잠시 동안 사용했지만 예외 처리했습니다. 궁극적으로 우리는 그것이 너무 많은 설정이었다. app.config의 구성은 주요 문제입니다. 모듈화가 아닙니다 (즉, 다른 소스의 구성을 쉽게 병합 할 수 없음).

유효성 검사 : 큰 팬이 아닙니다. 특별한 이유없이, 단지 많은 것을 적용 할 수 없었습니다.

결국 결국 사용자 지정 로깅 AB 만 사용합니다.

그래서 내가 구간의 정말 지침 아니라는 것을 동의 할 것) - 그들은 다양한 옵션을 제공하고 당신은 방법에 자신의 마음을 만들 필요가, 모든 일이 얼마나 유용에 대한 당신의 onw의 결론을 도출 그걸 써.

CAB (Composite UI AB) 사용 경험이 좋지 않았습니다. 불행하게도 우리는 지금 그것을 바꾸기에는 너무 멀다. 그러나 내가 같은 프로젝트를 다시한다면 나는 CAB를 전혀 사용하지 않을 것이다. 그것은 우리가 필요로하는 것만을 수행하는 것처럼 보이지 않으므로, 다른 어떤 것보다 더 많은 것을 의미합니다. 그리고 그것은 계속 진행되고있는 일을 모호하게 만듭니다.