AutoMapper와 같은 것이 필요하다는 것은 디자인이 좋지 않다는 것을 나타내는 것이 잘못입니까?

Automapper 는 .Net에 대한 "객체-객체 매퍼 (object-object mapper)"입니다. 이는 객체를 클래스에서 같은 것을 나타내는 다른 클래스로 복사하는 것을 의미합니다.

이것이 왜 유용한가? 클래스의 복제가 유용하고 좋은 디자인입니까?

빠른 구글 검색은이 예를 보여 주었다 :

http://www.codeproject.com/Articles/61629/AutoMapper

AutoMapper의 완벽하게 유효한 사용법을 보여줍니다. 이는 열악한 디자인의 예가 아닙니다. 계층화 된 응용 프로그램에서 데이터 또는 비즈니스 계층에 개체가있을 수 있으며 때로는 해당 데이터 개체의 특성 중 일부만 또는 UI 계층에서 해당 개체에 대한보기 만 필요할 수도 있습니다. 따라서 UI에 필요한 속성이 아닌 객체를 포함하는 뷰 모델을 작성하고 AutoMapper를 사용하여 해당 객체의 컨텐츠에 상용구 코드를 줄이십시오.

이러한 상황에서 "보기 개체"는 원래 클래스의 복제본이 아닙니다. 그들은 다른 방법과 아마도 몇 가지 중복 속성을 가지고 있습니다. 그러나 UI 표시 목적으로 만 해당 뷰 객체를 사용하고 데이터 조작이나 비즈니스 운영에 오용하지 않는 한 괜찮습니다.

이에 대한 이해를 돕기 위해 읽을 수있는 또 다른 주제는 CRUD와 달리 Fowlers Command Query Responsibility Segregation 패턴입니다. 데이터를 쿼리하고 데이터베이스에서 업데이트하기위한 서로 다른 개체 모델이 적합한 상황을 보여줍니다. 여기서 한 객체 모델에서 다른 객체 모델로의 매핑은 AutoMapper와 같은 도구로 수행 할 수도 있습니다.

클래스의 복제가 유용하고 좋은 디자인입니까?

데이터 계층에서 사용되는 것과 동일한 클래스를 사용하는 대신 UI 계층에서 별도의 뷰 모델 클래스를 사용하는 것이 좋습니다. UI / 웹 페이지는 데이터 엔터티와 엄격하게 관련되지 않은 다른 정보를 표시해야 할 수도 있습니다. 이 추가 클래스를 만들면 시간이 지남에 따라 요구 사항이 변경 될 때 UI를 쉽게 조정할 수 있습니다.

AutoMapper를 사용하는 한 개인적으로 3 가지 이유로 피합니다.

보다 일반적인 자동 실패

AutoMapper는 속성간에 자동으로 매핑되므로 한 클래스에서 다른 클래스가 아닌 속성 이름을 변경하면 속성 매핑이 건너 뜁니다. 컴파일러는 모른다. 오토 매퍼는 상관하지 않습니다.

정적 분석 부족

따라서 처리 할 큰 코드 기반이 주어졌습니다. 백만 개의 속성을 가진 백만 개의 클래스가 있습니다. 많이 사용되지 않거나 중복 된 것처럼 보입니다. Visual Studio의 "모든 참조 찾기"도구를 사용하면 속성이 사용되는 위치를 확인하고 전체 응용 프로그램이 어떻게 연결되는지에 대한지도를 작성할 수 있습니다. 그러나 Automapper가 사용 중이므로 속성의 절반에 대한 명시 적 참조는 없습니다. 내 직업은 이제 훨씬 더 어려워졌습니다.

복잡성을 증가시키는 최신 요구 사항

Automapper는 ONE 클래스에서 다른 클래스로 값을 복사하는 것만으로도 훌륭하고 멋집니다. 응용 프로그램의 다른 부분에서 값을 가져와야 할 수도 있습니다 (아마 로그인 한 사용자 또는 기타 상황에 따라 다름)?

응용 프로그램 시작시 일대일 클래스 매핑을 생성하는 AutoMapper의 패턴은 이러한 상황 별 변경에 적합하지 않습니다. 그렇습니다. 아마도 그것을 작동시키는 방법이있을 것입니다. 그러나 저는 보통 스스로 논리를 직접 작성하는 것이 더 깨끗하고 단순하며 표현력이 좋습니다.

요약하면, Automapper에 도달하여 한 클래스를 다른 클래스에 수동으로 맵핑하는 30 초를 절약하기 전에 이에 대해 생각해보십시오.

프로그래밍은 다른 사람에게 컴퓨터가 원하는 것을 알려주는 기술입니다. -도널드 크 누스

이를 염두에두고 "오토 매퍼가 오늘 도움이됩니까? 내일이 되겠습니까?"

내 경험상 누군가가 '너무 많은 상용구'에 대해 불평하고 AutoMapper를 사용하고 싶을 때 다음 중 하나였습니다.

1. 그들은 같은 코드를 반복해서 작성하는 것이 짜증나게합니다.
2. 그들은 게으르고 Ax = Bx하는 코드를 작성하고 싶지 않습니다.
3. 실제로 Ax = Bx를 반복해서 쓰는 것이 좋은 아이디어인지 생각한 다음 작업에 적합한 코드를 작성해야한다는 압박을 너무 많이받습니다.

하나:

1. 반복을 피하는 것이 중요하다면 객체 나 메소드를 만들어 추상화 할 수 있습니다. AutoMapper가 필요하지 않습니다.
2. 게으 르면 게으 르며 AutoMapper의 작동 방식을 배우지 못합니다. 대신, '우연히 프로그래밍'패턴을 채택하고 AutoMapper 프로파일에서 비즈니스 로직을 작성하는 끔찍한 코드를 작성합니다. 이 경우 프로그래밍에 대한 태도를 바꾸거나 직업으로해야 할 일을 찾아야합니다. AutoMapper가 필요하지 않습니다.
3. 시간이 너무 많이 걸리면 문제는 프로그래밍 자체와 관련이 없습니다. AutoMapper가 필요하지 않습니다.

정적으로 유형이 지정된 언어를 선택한 경우 해당 언어를 활용하십시오. AutoMapper와 같은 리플렉션 및 마법 API의 과도한 사용으로 인한 실수를 방지하는 데 도움이되는 언어로 컨트롤을 우회하려는 경우 이는 요구에 맞지 않는 언어를 선택했음을 의미합니다.

또한 Microsoft가 C #에 기능을 추가했다고해서 모든 상황에서 공정한 게임이거나 최상의 방법을 지원한다는 의미는 아닙니다. 예를 들어 리플렉션과 '동적'키워드는 필요한 것만으로는 달성 할 수없는 경우에 사용해야합니다. AutoMapper는 솔루션 없이는 해결할 수없는 사용 사례를위한 솔루션이 아닙니다.

그렇다면 클래스 복제가 나쁜 디자인입니까? 반드시 그런 것은 아닙니다.

AutoMapper가 나쁜 생각입니까? 네 그럼요.

AutoMapper의 사용은 프로젝트의 시스템 결함을 나타냅니다. 자신에게 필요한 것을 발견하면 디자인을 중단하고 생각하십시오. 항상 더 좋고, 더 읽기 쉽고, 유지 보수가 쉽고, 버그가없는 디자인을 찾을 수 있습니다.

여기에 더 깊은 문제가 있습니다 : 예를 : C # 및 Java는 모든 유형의 이름이 아닌 구조에 의해 구별 할 수 있어야합니다 / 대부분의 주장 사실 class MyPoint2D과 class YourPoint2D그들이 동일한 정의를 경우에도 별도의 종류는. 원하는 유형이 " x필드와 필드를 가진 일부 익명의 것 y"(즉, 레코드 )이면 운이 좋지 않습니다. 당신은을 설정하고자 할 때 그래서 YourPoint2D에 MyPoint2D, 당신은 세 가지 옵션이 있습니다 :

1. 지루하고 반복적이며 평범한 상용구를 작성하십시오. this.x = that.x; this.y = that.y
2. 어떻게 든 코드를 생성하십시오.
3. 반사를 사용하십시오.

선택 1은 소량으로도 충분하지만 매핑해야 할 유형의 수가 많을 때 신속하게 집안일이됩니다.

코드 2를 생성하기 위해 빌드 프로세스에 추가 단계를 추가하고 팀 전체가 메모를 받아야하기 때문에 선택 2는 바람직하지 않습니다. 최악의 경우 자체 코드 생성기 또는 템플릿 시스템을 롤링해야합니다.

그것은 당신에게 반성을 남깁니다. 직접 할 수도 있고 AutoMapper를 사용할 수도 있습니다.

Automapper는 황제가 말 그대로 엉덩이 주위를 돌고있는 라이브러리 / 도구 중 하나입니다. 화려한 로고를지나 치면 더 나은 결과를 얻을 수없는 수동 작업을 수행 할 수 없습니다.

자동 매핑 멤버를 암시하는 방법을 완전히 확신하지는 못하지만 추가 런타임 논리와 가능한 반영이 필요할 가능성이 큽니다. 시간을 절약하는 대신 성능이 크게 저하 될 수 있습니다. 반면 수동 매핑은 힌트를 컴파일 시간 전에 실행합니다.

AutoMapper에 실마리가없는 경우 코드 및 설정 플래그를 사용하여 매핑을 구성해야합니다. 모든 설정 및 코드 작업을 귀찮게하려면 수동 매핑보다 얼마나 많은 비용을 절약해야하는지 질문해야합니다.