Pergunta

Esta questão é mais de uma sonda para descobrir o que as pessoas estão fazendo na comunidade, em situações práticas, do que uma pergunta dirigida especificamente. Tenho pesquisado muito amplamente sobre isso, e enquanto eu encontrei um monte de blogueiros que defendem design de serviços contrato de primeiro e alguns comentários apoiá-las, eu ainda tenho que encontrar muita informação prática sobre a implementação de contrato de primeira com o WCF, os prós e contras de fazê-lo em um ambiente do mundo real, etc. Eu fiz recentemente uma pesquisa extensa em SOA, principalmente através de livros de Thomas Erl, e um dos principais conceitos que ele defende é o projeto contrato de primeira.

As minhas perguntas são as seguintes:

  1. Como você aborda design de serviços contrato de primeiro com .NET e WCF?
  2. Existem outras ferramentas além svcutil que pode gerar tanto o cliente e serviço de contrato? (Qualquer coisa que se integra com VS seria o ideal)
  3. O pros do mundo real você encontrou com design contrato de primeiro e WCF?
  4. O contras do mundo real você encontrou com design contrato de primeiro e WCF?

Um dos maiores problemas com o desenvolvimento contrato de primeiro parece ser ferramental. Svcutil é a única coisa que eu encontrei que pode gerar código de serviço a partir de um contrato, e tem alguma saída muito pobre. Seu single-arquivo, repleto de atributos e artefatos de geração de código, e que basicamente precisa ser regenerado e substituídos a qualquer momento o contrato é atualizado. Eu preferiria uma abordagem melhor, de preferência algo que não requer regen-substituir. Eu estou bem com a criação manualmente o contrato-side serviço mesmo, assumindo que é prática em um cenário do mundo real.

EDIT:

Enquanto WCSF resolvido minhas necessidades imediatas, aprendendo sobre Protocol Buffers e serviço da fábrica são ferramentas intrigante que estou certo vai me ajudar no futuro.

Foi útil?

Solução

FUMEC fornece uma ferramenta de contrato de primeira com a integração VS. Confira. (Livre)

A partir de 06 de julho, há uma versão binária com um programa de instalação.

Outras dicas

I usar uma abordagem contrato-em primeiro lugar, geralmente (mas nem sempre), usando o mesmo tipo de representação em cada extremidade.

Na verdade, usar WCF você não precisa de quaisquer proxies especiais etc; você pode usar os seus tipos regulares .NET em ambas as extremidades e não usar svcutil.exe em tudo . Conseguir um serviço de trabalho é tão simples como adicionar o "ABC" no arquivo de configuração, e usando algo como:

public sealed class WcfClient<T> : System.ServiceModel.ClientBase<T>
    where T : class
{
    public T Service { get { return base.Channel; } }
}

Agora você pode usar:

using(var client = new WcfClient<IMyService>()) {
    int i = client.Service.SomeMethod("abc");
}

e tudo que você tem no cliente (e servidor) é sua interface IMyService.


Para outras ferramentas; protobuf-net é uma implementação da API do Google "buffers de protocolo", que tem uma DSL para descrever dados e serviços em um "contrato de primeiro" (e portátil / interoperável) caminho - por exemplo (um arquivo .proto):

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}
message SearchResponse {
  repeated string result = 1; 
}
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

A ferramenta protobuf-net (que eu manter) inclui um utilitário "protogen" para transformar este DSL em C # / VB; e uma das opções (para C #, pelo menos - eu preciso verificar VB) está a emitir uma implementação de proxy WCF completo (com sua escolha de métodos síncrona ou assíncrona); muito semelhante ao Svcutil - mas (devido à relação protobuf-net) que inclui o atributo [ProtoBehavior] costume sobre a operação-contratos para que ele use o serializador protobuf-net em vez de DataContractSerializer (mais rápido e eficiente, mas diferente)

Para a integração VS; Eu estou trabalhando em exatamente isso ( prova ).

Eu prefiro desenvolvimento do contrato primeiro. Eu tenho usado o Serviço Fábrica para esta finalidade. Ele me permitiu gerar tanto o serviço e o código do cliente sem personalização.

com personalização, nós também foram capazes de gerar Transferência Data Objects correspondente a Entity Framework objetos, juntamente com o código para traduzir de um para o outro; registro automático de exceções; e documentação HTML dos serviços.

Esta é, para além das regras de análise de código que vêm com o Service Factory, que ajuda impedir que um desenvolvedor de atirar no próprio pé, escolhendo opções WCF incompatíveis.

Em WCF, você tem alguma diversidade O que há contrato de primeiros 'parece. Você pode fazer um 'contrato código primeiro', onde seus dados e contratos de serviços são expressos como tipos .NET com a marcação atributo direita. Você pode começar com WSDL e gerar os contratos de serviços e de dados, ou você pode começar com o esquema XML para o seu contrato de dados, e expressar o contrato de serviço como código. Que caminho você vai realmente depende da natureza do contrato e como ele será usado.

Se você está implementando algo para uma especificação WSDL, código gen de WSDL é a escolha óbvia, e gerando a partir de mão não é um negócio tão grande. Você poderia disparar a geração de um evento de compilação do projeto (ou entrar em msbuild) se quiser alterações no arquivo WSDL para propagar imediatamente.

Se você tiver esquema (XSD) existente que você deseja usar como um contrato de dados, ou preferem desenvolver seu contrato de dados dessa maneira para facilitar a reutilização em outras plataformas, você pode gerar tipos de esquema usando xsd.exe ( ou uma alternativa 3o partido). Neste caso, você usaria seus tipos XML-serializado em seu contrato de serviço orientada para o código como este :.

Se você está desenvolvendo os clientes e servidores se em .NET, e seus clientes podem chegar em suas montagens de contrato ou são clientes de geração felizes de metadados de serviço (por exemplo, WSDL), modelagem de seus contratos no código é uma grande experiência. Usando o esquema de "tipos conhecidos", você pode apoiar modelos de herança em seu contrato de dados, que pode ser muito poderosa. Você pode ignorar o código do cliente de geração inteiramente (como mencionado em outros respostas) referenciando diretamente o contrato de montagem em seu cliente. É muito produtivo e elegante, mas você precisa estar ciente de que você pode criar interoperabilidade desafios se você ficar muito extravagante.

A nossa forma de fazer isso é descrito neste vídeo:

http://www.dnrtv.com/default.aspx?showNum=103

A idéia é que nós não usamos a geração de código, nós, portanto, evitar a necessidade de código regenerado quando as mudanças de contrato.

O contrato é, então, no código e pode ser alterado, se existe uma incompatibilidade entre o cliente eo servidor ele vai aparecer em um erro de compilação.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top