비즈니스 라이브러리 재사용 또는 노출 서비스

Question

두 가지 가능한 디자인 중에서 선택하는 데 문제가 있습니다. 꽤 광범위한 비즈니스 계층과 DAL (웹 사이트, bll 및 dal은 모두 여러 개의 별도 dll에 있음)이있는 웹 사이트가 있습니다. 비즈니스 개체 중 일부를 가져 와서 파일에 쓰고 네트워크에 로컬로 저장할 수있는 Windows 서비스를 설계해야합니다. 그런 다음 파일을 타사 프로그램으로 가져와 추가 처리합니다.

1. 랩 비즈니스 계층과 DAL 주위 서비스 :

   나는이 서비스 두 가지 방법 중 하나를 디자인 할 수 있습니다. 이것은 쉽고 빠르지 만 비즈니스 계층이 바뀔 때마다 단점은 서비스가 업데이트되어야한다는 것입니다.

2. 웹 사이트에 웹 서비스를 추가하고 필요한 것을 웹 서비스에 쿼리하십시오. Windows 서비스는 비즈니스 계층을 사용할 필요가 없으며 웹 서비스가 변경되지 않는 한 좋을 것입니다. 유일한 단점은 웹 서비스의 XML을 파싱하기 위해 몇 가지 기본 비즈니스 객체를 만들어야한다는 것입니다.

windows 서비스는 10-20 분마다 비즈니스 계층/dal 또는 웹 서비스를 폴링해야합니다. 웹 사이트는 오프 사이트에서 호스팅되므로 우리의 로컬 리소스에 액세스 할 수 없으므로 Windows 서비스가 필요합니다. 나는 옵션 2쪽으로 기대고 있지만 찢어진 다.

더 나은 옵션은 두 가지입니다. 내가 고려하지 않은 다른 가능한 옵션이 있습니까? 또한 웹 사이트에서 주로 사용하는 핵심 라이브러리 집합이 있지만 데이터 검색이나 일부 기능을 수행하는 데 사용되는 상황에 대해 일반적으로 어떻게 설계합니까? 대신 비즈니스와 DAL, 주위 하드 포장 서비스의 대신 같은 설계 개념을 사용하기 (통합 웹 서비스를 통해) 웹 사이트에 의존하는 더 많은 유연성을

Answer 1

특정 비즈니스 개체를 네트워크에 파일로 저장하는 기준이 무엇인지 확실하지 않지만 정기적으로이 작업을 수행하는 경우 일종의 변경 내용을 추적하려고하는 것으로 추정됩니다. 또 다른 솔루션 : 비즈니스/지속성 계층에 직접 로직을 빌드하십시오.

이 보조 파일 저장소가 비즈니스 요구 사항 인 경우 해당 계층에 직접 포함시켜야하며 일종의 이벤트에 의해 트리거되어야합니다. 그렇게하면 시스템의 나머지 부분과 동기화되지 않는 애드 - 혹 포스트 프로세싱 (ad-hoc post-processing) 작업을하는 대신 하나의 일관된 시스템 만 갖추게됩니다.

웹 서비스를 비즈니스 서비스로 묶고 특별보고에 사용하는 대신 에 대한 데이터를 캡슐화하는 웹 서비스를 만들어 정기적으로 내보내기에서을 받고, 새로운 데이터가 준비되면 비즈니스 계층에서 메시지를 보내도록하십시오. 비즈니스 서비스를 묶지 않도록 비동기 적으로 메시지를 보낼 수 있으며 안정성 요구 사항에 따라 메시지 대기열을 설정할 수 있습니다 (WCF는 이미 전달 메커니즘으로 MSMQ를 사용하는 방법을 이미 알고 있습니다. 변경할 구성 설정이 거의 없음).

아키텍처, 데이터의 양과 유형, 일정 및보고 요구 사항 등에 대해 잘 모르는 상태에서 이것이 처음 두 옵션보다 낫다고 말할 수는 없지만 당신이 고려해야 할 것이 있습니다. 비즈니스 서비스가 상당히 자주 변경 될 가능성이 있다고 생각되면 마이닝 프로세스를 사용하지 않고 데이터를 "웨어 하우스"유형 추상화로 밀어 넣는 것이 더 효과적 일 수 있습니다.

그렇지 않으면 옵션 2를 사용할 것이라고 생각합니다. 이전에 WCF 서비스로 작업했는지는 알 수 없지만 실제로 XML을 구문 분석하지 않아야한다는 것을 알아야합니다. 모든 것은 데이터 계약을 통해 이루어지며 웹 서비스 용 프록시를 생성 할 때 강력하게 형식화 된 .NET 객체가 생성됩니다. 서비스 API를 통해 도메인 객체를 직접 전달할 수 있다면 웹 서비스를 작성하는 데는 거의 기능이 없습니다.

웹 서비스의 단점은 서비스 계약이 크게 변경되지 않도록 조치를 취해야한다는 것입니다 (그렇지 않으면 클라이언트가 손상 될 수 있음). 따라서 결국 도메인 개체를 통과하는 대신 공개 API로 사용할 서비스 측에서 데이터 전송 개체를 만들 필요가 있습니다. 그러나 많은 경우에 오랫동안이 작업을 수행 할 필요가 없으므로 계속 시도해보십시오. 매우 간단합니다.

Answer 2

: interface의, dynamic Type loading는 Inversion of Control 때문에 서비스입니다 비즈니스 및 DAL과 통신하고 서비스를 다시 컴파일하지 않고 비즈니스 및 DAL의 동적 업데이트를 허용하는 얇은 분리 층입니다. 기계의 Global Assembly Cache에 어셈블리를 넣어 다른 여러 프로젝트 어셈블리 및 응용 프로그램에서 공유 할 수 있습니다.

나는 그것을 위해 전문 용어를 버리는 것 같지만 그것이 내가 생각하기 시작할 것이라고 생각합니다.

편집 :

로드 유형을 동적으로 실제로 놀라운 쉽습니다. 이 방법은 한 가지 방법에 대한 빠른 C# 의사 코드이며 실제로 테스트하지 않아도됩니다. 유형 이름의 문자열 표현을 공식화하는 방법에 대한

// Get a System.Type from string representation 
Type t = Type.GetType("type name"); 
// Create instance of type. 
object o = Activator.CreateInstance(t); 
// Cast it to the interface (or actual Type) you're working with. 
IMyInterface strongObject = (IMyInterface)o; 
// ... and continue from there with the instance. 

지침은 Type.AssemblyQualifiedName, Type.GetType 및 이와 유사한 장소에서 MSDN에서 찾을 수 있습니다. 즉, 동일한 형식을 사용하기 때문에 app.config 또는 web.config 파일에서 많은 어셈블리 정규화 된 형식 이름을 볼 수 있습니다.

Answer 3

내가 알기 론,이 여분의 서비스를 위해 웹 API를 추가 할 것입니다. 따라서 변경 사항 (추가 서비스, 웹 API, dll)에 따라 두 부분을 업데이트해야합니다. 옵션 1을 사용하면 두 부분 (여분의 서비스, dll) 만 업데이트하면됩니다.

하지만 항상 유지 관리해야하는 일반적인 웹 API를 타겟팅하는 경우 옵션 2로 이동하십시오. 두 번째 옵션의

Answer 4

변종 :

기본 DTO의 DataContracts으로 필요한 정보를 노출 사이트에 WCF 서비스를 추가합니다. WCF 서비스 내에서 AutoMapper 또는 유사한 것을 사용하여 비즈니스 개체를 DTO로 변환하는 지루한 비트를 처리 할 수 ​​있습니다.