동료가 엔터프라이즈 개발에 데이터 세트를 사용하지 않도록 설득하는 방법(.NET 2.0+)

https://stackoverflow.com/questions/37378

09-06-2019
|

문제

나와 함께 일하는 모든 사람들은 엔터프라이즈 개발에 대한 데이터 중심 접근 방식에 집착하고 사용자 지정 컬렉션/개체를 사용하는 아이디어를 싫어합니다.그들을 설득하는 가장 좋은 방법은 무엇입니까?

해결책

레거시 코드(예: .NET 1.x에서 2.0 또는 3.5로 포팅된 앱)를 작업하는 경우 데이터 세트에서 벗어나는 것은 좋지 않습니다.이미 작동하는 것을 왜 바꾸나요?

그러나 새로운 앱을 만드는 경우에는 다음과 같은 몇 가지 사항을 언급할 수 있습니다.

경험에 호소 통증 DataSet을 사용하는 앱 유지 관리
새로운 접근 방식의 성능 이점을 언급하세요.
좋은 중간 지점으로 미끼를 던지십시오..NET 3.5로 이동하고 LINQ를 SQL로 승격하세요. 예를 들면 다음과 같습니다.여전히 데이터 기반 아키텍처를 고수하면서도 문자열 인덱스 데이터 세트에 대한 엄청난 변화를 가져왔습니다.짜잔!사용자 정의 컬렉션 - 숨겨진 방식으로.

중요한 것은 어떤 접근 방식을 사용하든 일관성을 유지하고 접근 방식의 장단점에 대해 완전히 정직하다는 것입니다.

다른 모든 방법이 실패할 경우(예: 기존 관행에서 벗어나는 것을 전혀 거부하고 새로운 것을 배우는 데 회의적인 개발 팀이 있는 경우) 이는 아주 아주 분명한 신호 당신이 팀보다 더 성장했다면 이제 회사를 떠날 시간입니다!

다른 팁

모범을 보이고 가볍게 밟으십시오.더 강한 것은 당신을 나머지 팀으로부터 멀어지게 할 것입니다.

당신이 놓친 것에 그들이 있을 가능성을 고려하는 것을 기억하십시오.팀의 일원이 된다는 것은 교대로 학습하고 가르치는 것을 의미합니다.

한 사람도 모든 답을 갖고 있지 않습니다.

당신이 놓친 것에 그들이 있을 가능성을 고려하는 것을 기억하십시오.팀의 일원이 된다는 것은 교대로 학습하고 가르치는 것을 의미합니다.

파견되었습니다."기업 개발"이 어떻게든 일반 개발과 다르다는 것(대개 그 의미는 '보다 더 중요하다')은 저를 정말 짜증나게 합니다.

일부 기술을 사용함으로써 실제로 이점이 있다면 전환할 경우 발생할 수 있는 모든 장단점을 고려한 목록으로 작성해야 합니다.
이 목록을 각 항목에 대한 설명 및 예와 함께 동료에게 제시하세요.

이 목록을 만들 때는 현실적이어야 합니다.단순히 "시간을 많이 절약해 주네요!!!"라고 말할 수는 없습니다.WIN!!'이라는 메시지를 표시하는 경우 때로는 더 많은 시간이 걸릴 것이라는 사실을 언급하지 않고 새로운 기술 등을 빠르게 적용하는 데 X개월이 걸릴 수도 있습니다.시간을 절약할 수 있는 구체적인 예와 방법을 보여주어야 합니다.

마찬가지로 당신도 단점이 중요하지 않은 것처럼 그냥 덮어버릴 수는 없습니다. 동료들도 마찬가지입니다. ~ 할 것이다 그쪽으로 전화해 보세요.
만약 당신이 이런 일을 하지 않거나 당신이 개인적으로 좋아하는 것을 단지 추진하는 것처럼 보인다면 아무도 당신을 진지하게 받아들이지 않을 것이고 당신은 열정과 에너지가 넘치지만 아무것도 모르는 사람이라는 평판을 얻게 될 것입니다. 무엇이든.

그런데.이 특별한 사기를 조심하세요.당신이 가지고 있지 않는 한 그것은 모든 것을 능가할 것입니다 많은 다른 모든 것에 대한 강력한 사례:

기존 코드를 포팅하는 데 12개월 이상의 작업이 필요합니다.당신은 패배합니다.

물론 상황에 따라 "다르다".때로는 매우 가벼운 비즈니스 논리, 엔터티/레코드의 평면 계층 구조 또는 일부 버전 관리 기능을 갖춘 경우 DataSet 또는 DataTable이 더 적합할 수 있습니다.

사용자 정의 객체 컬렉션은 구현을 원할 때 빛납니다. 깊은 계층구조/그래프 평면 2D 테이블에서는 효율적으로 표현할 수 없는 개체입니다.여러분이 보여줄 수 있는 것은 객체의 큰 그래프이며 다른 분기에서 부적절한 객체를 호출하지 않고 특정 이벤트가 올바른 분기로 전파되도록 하는 것입니다.이렇게 하면 하위 레코드를 얻기 위해 모든 DataTable을 반복하거나 선택해야 할 필요가 없습니다.

예를 들어, 제가 2년 반 전에 참여한 프로젝트에는 단일 WinForms DataGrid(더 구체적으로 말하면 Infragistics의 UltraGrid)에 질문과 답변 컨트롤을 표시하는 UI 모듈이 있었습니다.좀 더 까다로운 요구 사항

질문에 대한 답변 제어는 다음과 같습니다. 아무것 - 텍스트 상자, 확인란 옵션, 라디오 버튼 옵션, 드롭다운 목록 또는 웹 서비스에서 더 많은 데이터를 가져올 수 있는 사용자 정의 대화 상자 팝업까지 가능합니다.
사용자가 답변한 내용에 따라 상위 질문 바로 아래에 더 많은 하위 질문이 표시될 수 있습니다.나중에 다른 답변이 제공되면 해당 답변과 관련된 다른 하위 질문 세트(있는 경우)가 노출되어야 합니다.

원래 구현은 완전히 DataSet, DataTable 및 배열로 작성되었습니다.여러 테이블에 대해 수백 개의 행을 반복하는 양은 정말 놀라웠습니다.프로그래머가 C++ 배경에서 왔으나 도움이 되지 않았습니다. 심판 모든 것(안녕하세요, 힙에 살고 있는 객체는 사용합니다 참조 변수, 포인터와 같습니다!).원래 프로그래머조차도 코드가 왜 작동하는지 설명할 수 없습니다.그로부터 6개월이 지나서 현장에 왔는데, 여전히 벌레가 넘쳐났습니다.내가 물려받은 2세대 개발자가 그만두기로 결정한 것도 당연합니다.

혼란스러운 혼란을 해결하기 위해 두 달 동안 묶은 후 전체 모듈을 새로운 디자인으로 재설계했습니다. 이 문제를 해결하기 위한 객체지향 그래프.네, 추상 클래스(질문 유형에 따라 그리드 셀에 다른 답변 제어를 렌더링하기 위해), 대리자 및 이벤트가 포함되어 있습니다.최종 결과는 부모-자식 배열에 따라 자연스럽게 정렬된 심층적인 질문 계층 구조에 바인딩된 2D dataGrid였습니다.부모 질문의 답변이 변경되면 하위 질문에 대한 이벤트가 발생하고 부모의 답변에 따라 자동으로 그리드에 행을 표시하거나 숨깁니다.해당 경로 아래에 있는 질문 개체만 영향을 받았습니다.이전 방법과 비교하여 이 솔루션의 UI 응답성은 수십 배에 달했습니다.

아이러니하게도 이와 정반대의 질문을 올리고 싶었습니다.나와 함께 작업한 대부분의 프로그래머는 사용자 정의 데이터 개체/컬렉션 접근 방식을 사용했습니다.한 모니터에 SQL Server 테이블 정의가 열려 있는 누군가가 다른 모니터에 Visual Studio에서 일치하는 행 래퍼 클래스를 천천히 입력하는 모습(각 열에 대한 개인 속성과 getters-setter가 모두 포함되어 있음)을 보면 마음이 아픕니다.60열 테이블을 생성하는 경향이 있는 경우 특히 고통스럽습니다.이러한 클래스를 자동으로 빌드할 수 있는 ORM 시스템이 있다는 것을 알고 있지만 수동 접근 방식이 훨씬 더 자주 사용되는 것을 보았습니다.

엔지니어링 선택에는 항상 사용 가능한 옵션의 장단점 간의 균형이 필요합니다.DataSet 중심 접근 방식에는 사용자 정의 데이터 개체와 마찬가지로 장점이 있습니다(실제 db 데이터를 db 테이블과 같은 메모리 내 표현, 자신이 수행하는 작업을 알고 있는 사람들이 작성한 클래스, 대규모 개발자 풀에 익숙함 등). (컴파일 유형 검사, 사용자는 SQL 등을 배울 필요가 없습니다.)회사의 다른 모든 사람들이 DataSet 경로를 가고 있다면 적어도 기술적으로는 DataSet이 현재 수행 중인 작업에 가장 적합한 선택일 수 있습니다.

데이터 세트/테이블은 그렇게 나쁘지 않습니까?

제가 드릴 수 있는 최선의 조언은 자신의 코드에서 이를 최대한 많이 사용하라는 것입니다. 동료 리뷰와 버그 수정을 통해 다른 개발자들이 코드를 더 쉽게 읽을 수 있게 되기를 바랍니다.(이런 일이 발생하면 반드시 포인트를 누르세요).

궁극적으로 코드가 작동하면 나머지는 의미론이 내 견해입니다.

O/R 매핑 및 매퍼 도구 아이디어를 판매해 볼 수 있을 것 같습니다.행을 객체로 처리하면 매우 강력한 이점을 얻을 수 있습니다.

퍼포먼스에 집중하시면 될 것 같아요.DataSet과 사용자 지정 엔터티를 사용할 때 성능 차이를 보여주는 애플리케이션을 만들 수 있는 경우.또한 도메인 중심 설계 원칙과 그것이 엔터티 프레임워크에 어떻게 적용되는지 보여주십시오.

종교나 신앙에 관한 토론으로 만들지 마십시오.그것은 이기기가 어렵습니다(그리고 어쨌든 당신이 원하는 것은 아닙니다)

방금 질문에서 했던 방식으로 프레임을 구성하지 마세요.문제는 이런 방식이나 저런 방식이 그들이 일해야 하는 일반적인 방식이라는 데 누구도 동의하지 못하게 하는 것입니다.주어진 시간에 올바른 선택을 하기 위해 각자가 어떻게 생각해야 하는지에 대해 이야기해야 합니다.dataSet을 사용해야 하는 경우와 사용하지 않는 경우에 대한 예를 들어보세요.

개발자는 dataTable을 사용하여 데이터베이스에서 가져온 데이터를 저장한 다음 해당 dataTable을 사용하는 비즈니스 논리 코드를 갖게 되었습니다.그리고 웹 서버에서 100% CPU를 사용하는 데 7초가 걸리던 것에서 CPU 라인이 전혀 움직이는 것을 전혀 볼 수 없는 것으로 페이지 로드 시간을 줄이는 방법을 보여주었습니다.메모리 개체를 dataTable에서 Hash 테이블로 변경합니다.

따라서 다르게 구현하는 것이 더 나은 예나 사례를 선택하고 해당 전투에서 승리하십시오.높은 수준의 전쟁에 참여하지 마십시오 ...

상호 운용성이 문제가 될 경우 DataSet은 확실히 올바른 방향이 아닙니다.서비스를 통해 DataSet/DataTable을 노출할 수 있지만, 그렇게 해야 하는지 또는 논쟁의 여지가 있습니다..NET->.NET에 대해 이야기하고 있다면 아마도 괜찮을 것입니다. 그렇지 않으면 울타리 반대편에서 서비스를 소비하는 매우 불행한 클라이언트 개발자를 갖게 될 것입니다.

그렇지 않으면 그들을 설득할 수 없습니다.더 작은 과제를 선택하거나 다른 조직으로 이동하세요.관리자가 당신을 존중한다면 일종의 기술 시도로서 도메인 중심 스타일로 프로젝트를 수행할 수 있는지 확인하십시오.

프로파일링할 수 있다면 그냥 하고 프로파일링하세요.데이터 세트는 단순한 것보다 무겁습니다. Collection<T>

DataReader는 어댑터를 사용하는 것보다 빠릅니다.

개체의 동작을 변경하는 것은 데이터 세트를 마사지하는 것보다 훨씬 쉽습니다.

그래도:그냥 하세요, 허락이 아닌 용서를 구하세요.

대부분의 프로그래머는 자신이 익숙한 영역에서 벗어나는 것을 좋아하지 않습니다('대부분의 프로그래머' 세트와 '스택 오버플로' 세트의 교차점은 아마도 빈 세트일 것입니다)."이전에 효과가 있었다면(또는 방금 효과가 있었다면) 계속해서 수행하세요."제가 현재 진행 중인 프로젝트에서는 나이든 프로그래머가 CSV 파일(CSV를 사용한 이전 버전의 소프트웨어) 대신 XML/스키마/데이터 세트를 사용하도록 하기 위해 많은 논쟁이 필요했습니다.완벽하지는 않습니다. 스키마가 데이터 유효성을 검사할 만큼 강력하지 않습니다.그러나 그것은 올바른 방향으로 나아가는 단계입니다.제가 개발한 코드는 데이터 세트 개체를 전달하는 대신 데이터 세트에 대한 OO 추상화를 사용합니다.일반적으로 한 번에 작은 단계씩 예를 들어 가르치는 것이 가장 좋습니다.

여기에는 이미 아주 좋은 조언이 있지만, 스택오버플로우에 대한 몇 가지 지지적인 의견만 뒷받침하면 동료를 설득할 수 있는 일이 여전히 남아 있습니다.그리고 그들이 말하는 것처럼 회의적이라면 더 많은 탄약이 필요할 것입니다.먼저, 다양한 데이터 액세스 기술에 대한 자세한 분석이 포함된 Martin Fowler의 "엔터프라이즈 아키텍처 패턴" 사본을 구하십시오.읽어.그런 다음 그들 모두에게 그것을 읽도록 강요하십시오.

작업이 완료되었습니다.

데이터 중심은 코드 복잡성이 낮다는 것을 의미합니다.

사용자 정의 개체는 구성, 유지 관리 및 일반적으로 함께 사용할 수 있는 잠재적으로 수백 개의 추가 개체를 의미합니다.또한 조금 더 빨라질 것입니다.

제 생각엔 이것은 실제로 코드 복잡성과 성능에 대한 질문이며 앱의 요구 사항에 따라 답할 수 있습니다.

작게 시작하십시오.요점을 설명하는 데 사용할 수 있는 유틸리티 앱이 있나요?

예를 들어, 제가 일했던 곳에서는 기본 애플리케이션의 빌드 프로세스가 구성 파일 변경, 서비스 설치 등을 포함하여 복잡했습니다.

그래서 빌드 프로세스를 자동화하는 앱을 작성했습니다.기본적인 WinForms UI가 있었습니다.하지만 WPF로 전환하면서 Model-View-Presenter 덕분에 WinForms UI도 유지하면서 WPF UI로 변경했습니다.Model-View-Presenter에 익숙하지 않은 분들도 쉽게 참고할 수 있는 예시였습니다.

마찬가지로, 대규모 개발 투자를 하지 않고도 DataSet이 아닌 앱이 어떤 모습인지 보여줄 수 있는 작은 것을 찾으세요.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow