2010-06-23 5 views
1

나는 대답하기가 매우 쉽기를 희망한다. 내 회사의 공유 Employee 객체 라이브러리를 개발하려고합니다. 아이디어는 직원 (보고 계층 구조, 사무실 위치, 일반 정보 등)에 대한 정보를 포함하는 중앙 데이터베이스를 만든 다음이 데이터베이스에 대한 공유 개체 라이브러리를 만드는 것입니다.지속성이있는 공유 객체 라이브러리

내 질문은 응용 프로그램간에 공유 될 수 있도록이 라이브러리를 만드는 가장 좋은 방법입니다.

  • 데이터베이스 연결을 저장하는 자체 라이브러리를 만듭니다 (동시성 문제는 여기에서 볼 수 있지만 적절하지는 않습니다).
  • 클라이언트 -> 서버로 이동 한 다음 응용 프로그램간에 사용할 수 있도록 "클라이언트 라이브러리"를 배포하십시오.
  • 또는 웹/WCF 서비스가이 상황에 더 이상적으로 적합 할 것입니다.
+0

라이브러리는 데이터 라이브러리와 마찬가지로 직원 데이터 또는 라이브러리에 액세스하기위한 클래스 라이브러리를 의미합니까? – decyclone

+0

모든 응용 프로그램에서 직원 데이터에 액세스하도록 구현할 수있는 클래스 라이브러리를 의미합니다. – Aver

답변

1

질문이 광범위하게 번역 될 수 있기 때문에 많은 옵션이 있습니다. 나는 모든 대답에 마음을 돌리는 것이 좋습니다. 여기에 제 의견이 있습니다 ...

저는 소프트웨어 계층을 n 계층 교육으로 인해 수직으로 보는 데 익숙하지 않았고 개념적으로 더 넓고 덜 제한적인 개념으로 벗어나는 데 어려움을 겪었습니다. .NET 어셈블리를 퍼즐 조각으로 간주하려고 노력합니다.

코드에서 연결 문자열을 분리하는 것이 적절하며 .NET .config 파일 또는 응용 프로그램 설정에서 쉽게 지원됩니다.

저는 종종 비즈니스 로직, 개념 및 흐름을 갖는 작은 코어 라이브러리를 선호합니다.하지만 각각의 코어는 분리 될 수 있습니다. 그리고이 개념 내에서 여전히 데이터 액세스에서 다른 어셈블리로 비즈니스를 분리하여 새로운 종류의 데이터 액세스로 전환 할 수 있습니다. 그러나 핵심 모듈 (당신이 원한다면 "비즈니스 커널"또는 "엔진"의 일종)을 고수하십시오. 등을 윈폼, WPF, 실버 라이트, ASP.NET, LED/pixelboard :

당신은 예를 들어,

  • 텍스트/콘솔 IO
  • GUI를 많은 프리젠 테이션 형식을 통해 "비즈니스 커널"을 표현할 수 PowerShell 용 cmdlet이 같은
  • 웹 서비스 표현식 상호 작용 모바일 애플 리케이션의
  • 가지 등

패턴을 사용하여 소프트웨어를 사용자의 의지와 관련 구현에 맞게 가속화 할 수 있습니다 : Microsoft Enterprise Library, 종속성 삽입으로 커플 링 완화 예. Ninject (많은 것 중 하나) 또는 inversion of control 기술 등

1

보통 중간 계층 (클라이언트와 데이터베이스 사이의 일종의 웹/WCF 서비스)을 선호합니다. 이렇게하면 클라이언트를 데이터베이스에서 분리하여 연결 수를 제어하거나 클라이언트의 투명성을 유지하면서 데이터베이스 스키마를 변경할 수 있습니다.

상황에 따라 클라이언트를 WCF 서비스 (대부분의 경우 선호)에 연결하거나 서비스에 연결을 래핑하고 클라이언트 측에서 추가 처리를 수행 할 dll을 만들 수 있습니다.

1

라이브러리를 메인 애플리케이션에 얼마나 깊이 통합해야하는지에 따라 다릅니다. 사용자 정의 엔티티로 응용 프로그램 도메인을 확장하려면 다음 옵션이 있습니다.

  • 라이브러리에 지속성이 내장되어 있습니다. 연결 문자열을 저장소 클래스에 전달해야하지만 데이터베이스에도 라이브러리에 대한 하드 코딩 된 스키마가 있어야합니다. 데이터 액세스 라이브러리로 LINQ to SQL을 사용하는 경우 매핑 속성을 사용하여 엔티티를 마크 업할 수 있습니다.
  • 데이터 라이브러리가 POCO 매핑 (EF 4 do)을 지원하는 경우 도메인 라이브러리 만 제공하고 외부에서는 지속성을 구현합니다.

일반적으로, 분리 된 어셈블리로 도메인 모델을 두는 것은 몇 가지 문제가 발생합니다 응용 프로그램에

  • 통합. 응용 프로그램 자체는 일반적으로 데이터 액세스, 보안, 로깅, 웹 서비스 등과 같은 몇 가지 서비스를 제공합니다. 응용 프로그램에 이상적인 디자인과 레이어가 완전히 분리되어 있으면 새 엔터티를 추가해도 문제가 없지만 일반적으로 데이터 액세스 계층에는 로거는 싱글 톤이며 보안 검사는 비즈니스 로직 방법 등으로 하드 코딩됩니다. 이러한 응용 프로그램은 리팩토링되어야하며 서비스는 인터페이스로 추출되어야하며 그러한 인터페이스는 분리 된 어셈블리의 구성 요소로 전달되어야합니다.

  • 엔티티 참조. 리치 도메인 모델을 사용하는 경우 다른 어셈블리에서 선언 된 엔티티를 참조 할 수 있습니다. 부분적으로이 문제는 제네릭으로 해결할 수 있지만 일반 엔티티 목록을 얻거나 ID로 엔티티를 가져올 수있는 데이터 액세스 계층의 특수 디자인이 필요합니다.

  • 데이터베이스 통합. 일부 엔티티가 다른 팀과 별도로 개발되거나 다른 팀이 개발하는 경우 데이터베이스 변경을 유지하기가 어려울 수 있습니다.

0

연결 방법을 데이터 액세스 계층과 별도로 유지하고 요구 사항이 변경된 경우 나중에 연결 방법을 변경할 수 있습니다. 실제 논리를 보유하는 간단한 DLL을 가지고 있다면 맨 위에 통신 레이어를 추가하는 것이 간단해야합니다. 이것은 또한 위에서 언급 한 세 가지 방법을 모두 사용할 수있게 해주 며 모든 실제 논리를 단일 DLL에 모두 포함 시켜서 세 가지 모두에 사용할 수있게합니다.