문제

공통 문자열을 반환하는 대신 클래식 개체를 반환하는 방법이 있습니까?그렇지 않은 경우:모범 사례는 무엇입니까?개체를 xml로 바꾸고 반대편에서 개체를 다시 작성합니까?다른 가능성은 무엇입니까?

도움이 되었습니까?

해결책

언급한 대로 직렬화를 통해 .net에서 이 작업을 수행할 수 있습니다.기본적으로 모든 기본 유형은 직렬화 가능하므로 자동으로 발생합니다.

그러나 복합 유형이 있는 경우 [Serialized] 특성으로 객체를 표시해야 합니다.속성과 같은 복합 유형도 마찬가지입니다.

예를 들어 다음이 필요합니다.

[Serializable]
public class MyClass
{
    public string MyString {get; set;}

    [Serializable]
    public MyOtherClass MyOtherClassProperty {get; set;}
}

다른 팁

객체를 XML로 직렬화할 수 있고 WSDL로 설명할 수 있다면 웹 서비스에서 객체를 반환하는 것이 가능합니다.

예:.NET에서는 이 직렬화를 호출합니다. 여기서 개체는 XML로 직렬화된 다음 소비 서비스에 의해 다시 원래 개체 유형이나 동일한 데이터 구조를 가진 서로게이트로 재구성됩니다.

가능한 경우 개체를 XML로 변환합니다. 이는 웹 서비스의 이식성이 더 높다는 것을 의미합니다. 그런 다음 어떤 언어로든 서비스에 액세스할 수 있습니다. 해당 언어로 파서/객체 변환기를 생성하기만 하면 됩니다.

서비스를 설명하는 WSDL 파일이 있기 때문에 일부 시스템에서는 거의 자동화됩니다.

(예를 들어, C로 작성된 서버, C++/gSOAP로 작성된 클라이언트, Cocoa/Objective-C로 작성된 클라이언트를 대체하는 순수 Python으로 작성된 서버가 있습니다.우리는 Java로 작성된 테스트 프레임워크로 SoapUI를 사용합니다.

XML을 사용하여 웹 서비스에서 개체를 반환할 수 있습니다.그러나 웹 서비스는 플랫폼과 운영 체제에 구애받지 않아야 합니다.객체를 직렬화하면 파일과 같은 바이트 스트림에서 객체를 저장하고 검색할 수 있습니다.예를 들어 Java 객체를 직렬화하고 해당 바이너리 스트림을 변환(아마도 Base 64 인코딩을 통해 CDATA 필드로)하고 이를 서비스 클라이언트로 전송할 수 있습니다.

그러나 클라이언트는 해당 객체가 Java 기반인 경우에만 복원할 수 있습니다.또한 객체를 직렬화하고 정확하게 복원하려면 깊은 복사본이 필요합니다.깊은 복사본은 비용이 많이 들 수 있습니다.

가장 좋은 방법은 문서를 나타내는 XML 스키마를 만들고 개체 세부 사항을 사용하여 해당 스키마의 인스턴스를 만드는 것입니다.

.NET에서는 직렬화 가능한 개체를 사용하여 이 작업을 자동으로 수행합니다.나는 Java가 같은 방식으로 작동한다고 확신합니다.

다음은 .NET의 개체 직렬화에 대해 설명하는 문서입니다.http://www.codeguru.com/Csharp/Csharp/cs_syntax/serialization/article.php/c7201

@브라이언:Java에서 어떻게 작동하는지 모르겠지만 .net에서는 개체가 base64 문자열이 아닌 XML로 직렬화됩니다.웹 서비스는 웹 서비스에 필요한 메서드와 개체 정의가 포함된 wsdl 파일을 게시합니다.

나는 아무도 단순히 base64 문자열을 생성하는 웹 서비스를 만들지 않기를 바랍니다.

다니엘 오거:
다른 사람들이 말했듯이 가능합니다.그러나 서비스와 클라이언트 모두 양쪽에 동일한 도메인 동작이있는 객체를 사용하는 경우 처음에는 서비스가 필요하지 않을 수 있습니다.

최대:다소 좁은 의견이기 때문에 이것에 동의하지 않아야합니다.도메인 객체를 XML로 직렬화 할 수있는 웹 서비스를 사용하면 동일한 도메인 객체와 작업하는 클라이언트가 쉽게 작동하지만 해당 클라이언트는 노출 된 특정 웹 서비스를 사용하는 것으로 제한되어 있으며 다른 클라이언트가 도메인 오브젝트에 대해 알지 못하지만 XML을 통해 여전히 서비스와 상호 작용할 수 있도록합니다.

@로맥스:두 가지 시나리오를 설명했습니다. 시나리오 1: 클라이언트는 xml 메시지를 정확히 동일한 도메인 개체로 다시 수화하고 있습니다.나는 이것을 "객체 반환"이라고 생각합니다.내 경험상 이것은 나쁜 선택이며 아래에서 이에 대해 설명하겠습니다. 시나리오 2: 클라이언트는 xml 메시지를 정확히 동일한 도메인 개체가 아닌 다른 개체로 다시 수화합니다.나는 이것에 100% 배후에 있지만 이것이 도메인 개체를 반환하는 것으로 생각하지 않습니다.실제로 메시지나 DTO를 보내는 것입니다.

이제 웹 서비스 전반에 걸쳐 참/순수/비 DTO 객체 직렬화가 왜 필요한지 설명하겠습니다. 대개 나쁜 생각이다.주장:먼저 이 작업을 수행하려면 클라이언트와 서비스 모두의 소유자이거나 클라이언트에 사용할 라이브러리를 제공하여 개체를 실제 유형으로 다시 복원할 수 있어야 합니다.문제:유형으로서의 이 도메인 개체는 이제 두 개의 반관련 도메인에 존재하고 속합니다.시간이 지남에 따라 다른 영역에서는 의미가 없는 행동을 한 영역에 추가해야 할 수 있으며 이로 인해 오염이 발생하고 잠재적으로 고통스러운 문제가 발생할 수 있습니다.

나는 일반적으로 시나리오 2를 기본값으로 사용합니다.나는 그렇게 해야 할 압도적인 이유가 있을 때만 시나리오 1을 사용합니다.

첫 답변이 너무 간결해서 죄송합니다.이것이 내 의견이 어느 정도 명확해지기를 바랍니다.Lomax, 우리는 절반만 동의하는 것 같습니다 ;).

JSON은 (자바스크립트의 하위 집합으로) 웹에서 개체를 전달하는 매우 표준적인 방법입니다.많은 언어에는 JSON 코드를 기본 개체로 변환하는 라이브러리가 있습니다. 예를 참조하세요. 간단한 JSON 파이썬에서.

JSON 사용을 위한 더 많은 라이브러리는 다음을 참조하세요. JSON 웹페이지

다른 사람들이 말했듯이 가능합니다.그러나 서비스와 클라이언트 모두 양쪽에서 정확히 동일한 도메인 동작을 갖는 개체를 사용하는 경우 애초에 서비스가 필요하지 않았을 것입니다.

다른 사람들이 말했듯이 가능합니다.그러나 서비스와 클라이언트 모두 양쪽에 동일한 도메인 동작이있는 객체를 사용하는 경우 처음에는 서비스가 필요하지 않을 수 있습니다.

다소 좁은 의견이므로 이에 동의하지 않습니다.도메인 개체를 XML로 직렬화할 수 있는 웹 서비스를 사용한다는 것은 동일한 도메인 개체로 작업하는 클라이언트가 쉬워진다는 것을 의미합니다. 다른 클라이언트가 귀하의 도메인 개체에 대해 알지 못하더라도 여전히 XML을 통해 귀하의 서비스와 상호 작용할 수 있도록 허용함으로써 그 반대가 됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top