1. 홈
  2. 질의 응답
  3. 최상의 솔루션 : 확장 메서드 또는 새 클래스?

최상의 솔루션 : 확장 메서드 또는 새 클래스?

2011-10-11 3 views
2

그래서 나는 이것에 대한 악마의 옹호자를 시도해 볼 것입니다 ...최상의 솔루션 : 확장 메서드 또는 새 클래스?

가끔씩 2 개 또는 3 개의 다른 웹 사이트를 서비스하는 프레임 워크가 있습니다. 프레임 워크의 기본 기능은 특정 DB에 대한 모든 호출을 처리하는 것입니다. DB 호출을 할 때 웹 사이트는 Framework DataSource 객체를 호출하고 일반 Framework 데이터 객체를 반환합니다.

웹 사이트가 특정 요구 사항에 맞는 속성/방법을 검색 할 수 있도록 이제 2 가지 솔루션 옵션이 제공됩니다.

  1. 이 새로운 클래스의 내부의 도메인 특정 기능을 유지 노출 이상의 도메인 친화적 인 특성 &, 확장 또는 일반 데이터 객체를 포장, 새로운 클래스를 생성합니다.

  2. 새 클래스를 만드는 대신 프레임 워크 내에서 확장 메서드를 만들어 각 웹 사이트에 제공합니다. 프레임 워크에 포함 된 내용은 모두 이며 웹 사이트간에 공유 할 수 있습니다. 1 일 필요시.

그냥 예 것 여기 명확히 : 속성 : NewObject.GetSiteSpecificProperty

  • GenericObject.GetProperty ("GetSiteSpecificProperty") 또는 GenericObject.GetSiteSpecificProperty()

    방법

    1. NewObject.DoSomethingSpecificToThisWebsite()
    2. GenericObject.DoSomethingSpecificToThisWebsite()

    그래서 당신은 어떤 솔루션을 선택하는 것? 1 또는 2?

    건배.

    • 출처

    2011-10-11 Kevin M

    +0

    당신은 확장 메서드를 사용하지 않고 방법을 공유 할 수 있습니다 읽어 보시기에 공유 물건을 밀어 줄 잠시 동안 수 있도록 설계 프레임 워크를 디자인하는 경우 기본 클래스 – Joey

    +0

    내가 묻는 것의 요점을 놓치고 있거나 내 질문을 분명히하고 있지 않다. 웹 사이트간에 정보를 공유하는 방법을 묻지 않고 있습니다. 제 질문은이 문제에 가장 적합한 디자인 솔루션입니다. 1 또는 2? 그리고 왜? –

    +0

    자, 확장 기능은 웹 사이트간에 메소드를 공유하는 유일한 옵션이 아니므로 기능 공유가 결정에 포함되어서는 안된다는 것을 지적했습니다. FWIW 나는 그것이 사용 된 특정 기능을 유지하기 때문에 1로 갈 것이다. 기본 래퍼 클래스에 공유해야 할 가능성이있는 기능을 넣으십시오. – Joey

    답변

    1

    제 생각에는 프레임 워크를 디자인 할 때 프레임 워크에서 많은 솔루션 특정 측면을 유지하고 가능하면 호출하는 엔터티를 처리해야합니다.

    프레임 워크가 얼마나 많은 웹 사이트/프로젝트에 사용되는지는 확실치 않지만 옵션 (2)을 사용하면 이제 새 웹 사이트가 추가 될 때마다 프레임 워크가 이제 작업해야합니다. 이 기능을 완료하려면 맞춤 방식으로 프레임 워크를 사용하는 작업은 프레임 워크가 아닌 웹 사이트에서 처리해야합니다. 이 프레임 워크가 10 개 또는 100 개의 웹 사이트를 사용하게되면 유지 관리가 절대적으로 어려워지고 프레임 워크가 솔루션 특정 제품과 같이 프레임 워크처럼 보이지 않게됩니다. (1)은 훨씬 깨끗한 해결책입니다. 기본적으로 프레임 워크를 재사용 가능하고 솔루션에 무관심하게 유지하십시오.

    당신은 많은 다른 프로젝트에서 사용하고있을 것이며, 내가 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)

    출처

    2011-10-11 20:43:45

    +0

    나는 그것이 내가 바라는 이론 측면에 더 있기 때문에 tke에 대한 답을 얻었다. KeithS의 대답은 내가 할 수 있다면 좋을 것입니다. 나는 (1) 캠프에 분명히 있지만, 내가 올바른 방향으로 가고 있음을 확인하고 싶었습니다. (2) 방금 너무 반 OOP 것 내가 받아 들일 수있는 해결책 인 그것의 주위에 나의 머리를 얻을 수 없었다. 고마워요. –

    0

    제 생각에는 기본 클래스를 만들고 사이트 별 코드에 재정의를 사용하는 것이 더 좋습니다. 그들은 그것을 할 수는 있지만, 확장 메소드가 이러한 유형의 조작을 위해 만들어진 것처럼 보이지 않습니다.

    다른 웹 사이트에서 공유 프레임 워크를 사용하여 다른 값을 얻는 방법을 찾고 있다면 web.config가 그러한 필요성에 부합하는 것처럼 보입니다. 각 사이트는 자신의 Web.Config를 가질 것이고 거기에 필요한 특정 속성 값을 채울 수 있으며 그 값을 검색하는 단일 함수를 가질 수 있습니까?

    출처

    2011-10-11 20:41:55 Brosto

    1

    일반적으로 확장하려는 클래스의 소스를 제어하는 ​​경우 확장 메소드 대신 상속으로 확장합니다. 확장 메서드는 .NET 기본 제공 (String, Enum, IEnumerable) 및 기타 타사 개체와 같이 제어하지 않는 클래스에 사용자 지정 기능을 추가하는 데 유용합니다. 그러나 구성하기가 어려울 수 있으며 기술적으로 정적 인 방법입니다. 일반적으로 시작 성능과 메모리 사용량 측면에서 최소화하려는 경우가 많습니다.

    확장 프로그램으로 이동하면 네임 스페이스 및 메서드 확인 문제가 발생할 수 있습니다. 확장 메서드를 사이트 별 라이브러리에 저장한다고 가정 해 보겠습니다.한 사이트가 다른 사이트와 동일한 사이트 관련 작업을 수행해야하는 경우 다른 사이트에 확장 방법을 포함하는 하나의 사이트 라이브러리를 포함시켜야합니다 (코드에 대해 알고 싶지 않은 다른 것들을 노출 시키거나 중복 된 객체를 포함 할 수 있음) 또는 확장)을 작성하거나 코드를 복제 (DRY 위반) 할 수 있습니다.

    출처

    2011-10-11 20:42:09 KeithS

    +0

    안녕하세요. 정적 방법과 시작 성능/메모리에 대해 너무 많이 생각한 적이 없었습니다. 발자국. 요즘 일반적인 서버에서 이것이 현실적인 문제입니까? –

    +0

    웹 사이트가 근본적으로 서비스 (가동 시간이 높고 재시작 횟수가 적을 것으로 예상 됨)이기 때문에 특히 중요하지 않습니다. 그러나, 그것은 약간의 효과가있을 것입니다. – KeithS

    +0

    예를 들어 캐싱이 웹 사이트가 매시간 정적/확장 메소드를 재시작해야 할 필요가있는 서버에서 캐싱이 너무 어려워서 문제가 있다고 가정 해 보겠습니다. –

    0

    프레임 워크를 일반 (재사용 가능) 및 특정 기능이 사용되는 곳과 유지 보수 프로그래머 인 경우 어디에 보일지를 알기 때문에 1로 갈 것입니다.

    기능을 공유하려면 특정 래퍼에서 파생되는 기본 래퍼 클래스를 만듭니다.

    출처

    2011-10-11 20:42:19 Joey

    관련 문제

     관련 문제