Fluent NHibernate와 Dapper-dot-net을 혼합 할 때 발생할 수있는 문제점은 무엇입니까?

.net dapper fluent-nhibernate

문제

나는 Fluent NHibernate를 사용하여 몇 년 동안 프로젝트를 지원해야했고 솔직히 그것에 지쳤다. 앞으로 Dapper-dot-net ( https://github.com/StackExchange/dapper-dot-net )을 사용하고 싶지만, 일부 팀은 두 개의 ORM 프레임 워크를 하나의 프로젝트로 섞어서 사용하는 것에 반대합니다.

그들의 우려는 정당한가? NHibernate와 Dapper (또는 다른 ORM 프레임 워크)가 같은 프로젝트에 함께 존재할 수없는 이유를 나열 할 수있는 경험이있는 사람이 있습니까?

감사,

수락 된 답변

첫째, 같은 프로젝트에서 Fluent NHibernate (FNH)와 Dapper를 직접 결합한 경험이 없으므로 염두에 두십시오! 그러나 나는 별도의 프로젝트에서 FNH, Entity Framework 및 Dapper를 독립적으로 사용했으며, 단순성 때문에 정확한 프로젝트를 위해 Dapper를 선택했고 더 많은 중량의 ORM을 피하려고했습니다. 더 많은 기능을 통해 Dapper의 매력을 개인적으로 볼 수 있습니다. 풍부한 대안. 두 크리크 € ™의 (t)가 자체 같은 프로젝트에 존재하는 이유 이유가 없지만, 당신의 팀 (같은 프로젝트에 다른 데이터 액세스 기술을 도입에 대해 이의를 제기 완벽하게 정당화 생각하지만 이러한 우려는 이동의 장점을 능가하는지 여부 물론 Dapper는 팀의 특정 요구 사항에 따라 달라집니다.

마음에 떠오를 몇 가지 즉각적인 기술적 고려 사항 / 우려 사항 :

  • 모든 기능을 갖춘 ORM과 ADO.NET의 얇은 래퍼간에 정신적 컨텍스트를 전환합니다. 비록 사소한 경우를 대체 :

    쿼리 (a => a.Id == id && a.Active == true) ...

    "WHERE id = @Id AND active = true"...

    커다란 정신적 인 도약이 될 수는 없습니다. 디버깅 할 때 FNH를 사용하는 쿼리와 원시 SQL을 사용하는 쿼리 사이를 전환하는 것은 이해할 수 있습니다. 그 반대의 경우도 특히 팀에 가장 유쾌한 경험이 될 수 없습니다 복잡한 검색어

  • 현재와 ​​같이 Dapper 쿼리를 사용하여 동일한 도메인 엔터티를 반환하거나 사용할 계획입니까? 그렇다면 지연로드 (현재는 사용하고 있지만 Dapper에서는 제공되지 않을 수도 있음) 및 엔티티 관계와 같은 기능을 복제해야하는 경우 문제가 발생합니까?

  • Dapper는 SQL 쿼리를 직접 작성해야합니다. 팀이 원시 SQL보다 LINQ 스타일 쿼리를 적극적으로 쓰기 때문에 FNH가 선택되었거나 더 중요한 것은 SQL에 익숙하지 않기 때문에 Dapper를 도입하면 팀이 SQL 학습 곡선을 강요하게됩니다.

  • Dapper는 쿼리에 대한 컴파일 시간 검사를 제공하지 않으므로 일반적으로 유창한 매핑과 쿼리에서 선택되는 엔티티의 변경 사항 (팀이 편안하고 의존 할 수 있음)에 플래그가 지정되지 않습니다.

좀 더 일반적인 관심사는 장기간에 걸쳐이 두 가지를 어떻게 처리 할 것인지 계획하는 것입니다. 나는 당신의 특정 프로젝트에 익숙하지 않고 얼마만큼의 FNH 기능을 사용했는지 잘 모르겠다. 그래서 다음과 같은 사항은 문제가 될 수있다. 그러나 기존의 코드베이스를 그대로 둔 채로 dapper만을 사용하고자한다면 아마 다음과 같은 누군가를 유지해야 할 것이다. FNH 기능을 많이 사용하는 복잡한 쿼리가 심하게 리팩토링되거나 디버깅 될 필요가있는 경우 FNH를 사용하는 전문 기술


인기 답변

그냥 명확히하기 위해 : 당신이 물어 보는 것은 동일한 프로젝트에서 nHibernate와 Dapper를 함께 사용하는 것입니다. (Fluent nHibernate는 ORM이 아니며 매핑에 도움이되는 라이브러리입니다.)

몇 년 동안 nHibernate + FNH를 사용 해왔고, 성능 향상을 위해 Dapper.net을 소개 한 마지막 두 웹 프로젝트에서. 내 프로젝트는 CQS 를 사용하여 작성되었으므로 쓰기 (명령)에 nHibernate를 사용하고 읽기 (쿼리)에는 Dapper.net을 사용할 수 있습니다. 이것은 나에게 nHibernate의 파워와 빠른 읽기 측면을 제공한다.

두 가지를 섞어서 팀이 할 수있는 문제점 :

  • 프로젝트 아키텍처가 변경하기에 적합하지 않거나 어렵다.
  • SQL을 수동으로 작성하기위한 추가 작업이 필요합니다.
  • 엔티티 매핑 또는 DTO 생성 및 매핑을위한 추가 작업이 필요합니다.
  • 그것을 도입 할 때 실질적인 이익은 없다.

당신이 nHibernate에 지쳐 있기 때문에 그것을하고 싶다면 걱정해야 할 좋은 이유가 있습니다.



아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow