BlogServiceHost.Create()

Contract-First vs Code-First

La discussione percorre la rete ormai da diverso tempo, ma vorrei capire effettivamente qual'è l'orientamento di noi italiani. Abbiamo:

• Code-First
• Sviluppo rapido
• Definizione del contratto poco preciso
• Contract-First
• Sviluppo meno rapido
• Definizione del contratto moolto più precisa

Nel primo caso è il codice da noi scritto che genera il contratto (il wsdl), mentre nel secondo caso il codice o, meglio, l'interfaccia che rappresenta il contratto nel nostro linguaggio di sviluppo, viene generata partendo dal WSDL. Con il Code-First lo sviluppatore, in alcuni casi, può non essere cosciente di cosa accade ad ogni modifica del servizio da lui scritto. Inconsciamente può mettere un dataset, per dirne uno, come parametro di un servizio. Non che questo non deve essere fatto, ma se dobbiamo essere interoperabili e soprattutto guardare al futuro (chi vieta a microsoft di modificare il dataset?) è un qualcosa assolutamente da evitare.
Nel Contract-First, invece, il contratto viene stabilito e "disegnato" a priori. E' poi compito dello sviluppatore rispettarlo ed implementarlo nel linguaggio che più gli è consono. Questo costringe lo sviluppatore a rispettare senza mezzi termini quanto stabilito dal contratto.

Questa è la mia visione e sono contento di condividerla, e magari essere contraddetto, con voi. Senza dubbio uno sviluppatore attento alle sfumature è capace di assottigliare la differenza delle due metodologie. Voglio sottolineare che ognuna ha vantaggi e svantaggi ed è un bene scegliere la più opportuna.

Un'ultima nota: Contract-First non vuol dire realizzare l'interfaccia e mettergli l'attributo ServiceContract, ma significa avere un WSDL (il contratto nei web services) per poi realizzare l'interfaccia che il nostro servizio deve implementare.

La discussione, se volete, è aperta.