네트워크 클라이언트가

Question

컨텍스트를 호출 할 수있는 API를 노출. 이 컴퓨터에서는 이러한 장치를 제어 할 수있는 프로그램을 만들고 각 장치에 명령을 보내어 구성을 변경하거나 주어진 시간대에 대해 기록 된 데이터를 검색하는 프로그램을 만들 예정입니다.

은이 프로그램의 모든 기능은 또한 네트워크의 다른 컴퓨터에 사용할 수있게하려면. 는 "개념의 증거"를 들어 나는 그런 내가 WCF가 자동으로 Visual Studio에서 서비스에 대한 프록시 클래스를 만들 수 있으며, 직접 작업 할 수 있었다으로 좋아 무엇

void SetTime(string comPort, DateTime time) 
DateTime GetTime(string comPort) 
List<string> GetSensors(string comPort) 
List<LoggedValue> GetLoggedData(string comPort, string sensorName, DateTime start, DateTime stop) 
void RestartDevice(string comPort) 

같은 기능을 가진 간단한 WCF 서비스를 만든 서비스에 정의 된 사용자 정의 클래스 (예 : LoggedValue).

그러나 WCF가 너무 복잡하고 높은 오버 헤드가 있으며 asp.net 웹 API (또는 mvc 웹 API 2 또는 무엇이든간에)가 API를 만드는 방법이라고 주장하는 많은 주장이 있습니다. (간단한 HTTP 요청)과 낮은 오버 헤드를 호출하기 쉽습니다. 이 두 가지 점에 동의 할 수는 있지만 WCF의 강력한 형식의 클래스를 사용하면 많은 이점을 잃어 버리게됩니다.

또한 "CRUD"- 작동이 내가하고 싶은 모든 작업을 항상 잘 수행하지는 않습니다. Create 또는 Delete 작업을 절대로 수행하지 않으며 로깅 간격 설정과 같이 구성 값을 변경하는 경우에만 Update이 변경됩니다. void RestartDevice(string comPort)과 같이 API에서 값을 반환하지 않는 함수를 호출하면 웹 API에서 부자연스러워 보일 수도 있습니다. 어떻게 수행할까요?

두 기술 중 어느 것에도 너무 많은 경험이 없으므로 가장 자연스럽게 사용합니까? 이것은 많은 클라이언트가 액세스 할 수있는 서비스가 아니며 요청 비율이 매우 낮습니다. 당신은 개념의 증거를 수행하는 경우

Answer 1

나는 WebAPI이 약간 간단하게 구현하는 것에 동의합니다. 나는 거의 10 년 동안 WCF를 사용 해왔고 WebAPI를 3 년 동안 사용해 왔지만 요즘 WCF를 거의 사용하지 않는다. WebAPI를 사용하는 것은 HttpClient을 사용하여 매우 간단합니다.

난 당신이 궁극적으로 가고있는 기술 스택을 통해 공공연히 자신을 걱정할 필요가 생각하지 않습니다. 두 기술 모두 RPC에 대한 요구 사항 또는 명령 스타일 작업을 지원하며 둘 다 잘 지원되고 사용하기 쉽고 대략 동일한 관리 오버 헤드가 있습니다.

귀하의 장치 운영 계약이 RESTful 작업 집합으로 쉽게 표현 될 수 없다는 점에 동의합니다. 따라서 WebAPI를 선택하면 단지 Verbage (GET, PUT 등) 주변의 conventions을 모두 무시하고 모든 명령에 대한 POST.

Answer 2

, 당신은뿐만 아니라 NetMQ 하나를 시도 할 수 있습니다. 그것의 ZermMQ의. NET 포트, 그리고 그것을 편리하게 사용할 수있는 nuget 패키지가 있습니다.

물론, WCF는 좋은 유연한 솔루션이다. 통신 전략에 따라 pub/sub 또는 broadcast 모델을 사용하면 웹 API로 할 수없는 일을 할 수 있습니다.