WCF model in andere namespace

[Snake]

Deze is wat moeilijk uit te leggen, maar ik ga toch proberen:


Ik heb een service, met de volgende folderstructuur:

code:

MyWCFService
|-IService.svc
|-MyServiceImplementation.svc + code behind
\-Models
 |-Model.cs

Waarbij Models een dir is en daarin zit dus Model.cs onder de namespace MyWCFService.Models.

Dus als ik nu mijn Model NIET in mijn service gebruik verschijnt deze ook niet in mijn WSDL. Maar dat wil ik dus wel. Iemand enig idee hoe ik dat kan forceren?

Gebruik ik deze in m'n IService dan is het geen probleem. Maar dat wil ik dus niet. Hij moet bestaan als apparte entiteit.


Edit: natuurlijk zit ik al x aantal tijd te Googlen. Dit heeft helaas niets opgeleverd, aangezien ik tegen het namespace attribuut van DataContract loop, wat dus niet is wat ik wil hebben.

[ Voor 28% gewijzigd door Snake op 14-12-2009 13:02 ]

[TheNameless]

Ik heb het niet getest, maar misschien als je je types registreerd via een ServiceKnownTypeAttribute, dat hij wel in de WSDL komt.

Dit attribuut is niet helemaal daar voor bedoelt, maar misschien dat het werkt.

Op deze manier dus:

C#:

namespace MyWCFService
{
    [ServiceContract]
    [ServiceKnownType(typeof(Models.Model))]
    public interface IService
    {
    }
}

[ Voor 37% gewijzigd door TheNameless op 14-12-2009 13:10 ]

[Snake]

Dit ZOU moeten werken volgens de spec van dat Attribute, helaas vind ik het NIET terug in de WSDL. Maar ik zoek verder.

[TheNameless]

Snake schreef op maandag 14 december 2009 @ 13:35:
Dit ZOU moeten werken volgens de spec van dat Attribute, helaas vind ik het NIET terug in de WSDL. Maar ik zoek verder.

Kan het soms zijn dat je er misschien overheen kijkt?
Want ik kan me herinneren dat de type definities geïmporteerd worden in je WSDL (via een XSD bestand).

[Snake]

TheNameless schreef op maandag 14 december 2009 @ 13:52:
[...]

Kan het soms zijn dat je er misschien overheen kijkt?
Want ik kan me herinneren dat de type definities geïmporteerd worden in je WSDL (via een XSD bestand).

Ik zie het niet terug in de object browser van het project wat de WCF service consumed.

[Snake]

Ik ben tot de volgende conclusie gekomen:

Het model wat ik probeer toe te voegen is eigelijk een LINQ to SQL model.

Als ik gewoon een model (bestaande uit een string oid) toevoeg met ServiceKnownType dan werkt het perfect.

Als ik een LINQ to SQL gebruik in mijn Service ZELF dan werkt het ook.

Maar een ServiceKnownType naar een LINQ to SQL generated class werkt niet

[D-Raven]

De ServiceKnownTypeAtribute zou moeten werken. Maak anders een KnownTypesProvider class ofzo, waar je alles binnen je namespace in registreert als de app opstart. Vervolgens kun je hem als volgt op je interface toepassen:

C#:

[OperationContract(..);
[ServiceKnownType("GetKnownTypes", typeof(KnownTypeProvider))]
Response Doeiets(Request blaat);

Ik vermoed namelijk dat je niks ziet omdat niet al je types zijn opgenomen. Een voorbeeld voor zo'n classe kun je hier vinden.

edit: ok iets sneller typen vervolgens

Geen idee hoe een gegenereerde LinqToSql classe eruit ziet maar een normale LinqToSql entity classe werkt met attributes om zijn mapping naar de DB te definiëren. Kan me niet voorstellen dat het met gegenereerde classes anders zou moeten zijn. Dat gezegd kan ik maar weinig bijzonderheden vinden omtrent het gebruik van LinqToSql entities met WCF.

Dus mits dat je de DataContracts gedefinieerd hebt zou het AFAIK moeten werken.

[ Voor 33% gewijzigd door D-Raven op 14-12-2009 15:20 ]

[TheNameless]

Snake schreef op maandag 14 december 2009 @ 15:01:
Ik ben tot de volgende conclusie gekomen:

Het model wat ik probeer toe te voegen is eigelijk een LINQ to SQL model.

Als ik gewoon een model (bestaande uit een string oid) toevoeg met ServiceKnownType dan werkt het perfect.

Als ik een LINQ to SQL gebruik in mijn Service ZELF dan werkt het ook.

Maar een ServiceKnownType naar een LINQ to SQL generated class werkt niet

Hebben je entities een default constructor (zonder argumenten dus)?
Dit is namelijk nodig, anders kan je entity niet geserialized worden.

Is het trouwens wel handig om je Linq To Sql entities te "exposen" bij je webservice? Een DTO/viewmodel/whatever achtige oplossing lijkt beter geschikt hiervoor.

Je krijgt zo wel wat extra klassen erbij, maar hoeft niet veel werk extra te zijn als je bijvoorbeeld gebruik maakt van bijvoorbeeld Automapper

[TheNameless]

D-Raven schreef op maandag 14 december 2009 @ 15:10:
.....
Dus mits dat je de DataContracts gedefinieerd hebt zou het AFAIK moeten werken.

Dit hoeft niet meer sinds .NET 3.5 SP1 (schijnt).
Klasses kunnen nu geserializeerd worden als ze een default constructor hebben.
Alle public properties worden dan meegenomen.

[Snake]

LINQ to SQL objecten hebben een parameterless constructor. En je moet de Serialization Mode van de dbml op Unidirectional zetten. Dan werkt het allemaal.

En waarom zou ik ze niet exposen? Het is alleen maar voor read only (wat images met wat data). Enkel de changes worden teruggestuurd (niet de hele entities).

[D-Raven]

TheNameless schreef op maandag 14 december 2009 @ 15:25:
[...]


Dit hoeft niet meer sinds .NET 3.5 SP1 (schijnt).
Klasses kunnen nu geserializeerd worden als ze een default constructor hebben.
Alle public properties worden dan meegenomen.

Ah, klopt helemaal, was ik even vergeten.

[D-Raven]

Snake schreef op maandag 14 december 2009 @ 15:35:
En waarom zou ik ze niet exposen? Het is alleen maar voor read only (wat images met wat data). Enkel de changes worden teruggestuurd (niet de hele entities).

Betere scheiding van verantwoordelijkheden voornamelijk. Mede doordat je nu direct je database entiteiten direct wil exposen in WCF loop je tegen deze problemen aan.

Maargoed als ik een simpel progje zou hebben dan zou ik zelf de moeite ook niet doen denk ik. Tenminste zolang het een kwestie is van ergens een "schakelaar" omzetten.
Overigens hoef je dit bij NHibernate entiteiten niet te proberen. Daar komt wel iets meer bij kijken

[TheNameless]

Snake schreef op maandag 14 december 2009 @ 15:35:
LINQ to SQL objecten hebben een parameterless constructor. En je moet de Serialization Mode van de dbml op Unidirectional zetten. Dan werkt het allemaal.

En waarom zou ik ze niet exposen? Het is alleen maar voor read only (wat images met wat data). Enkel de changes worden teruggestuurd (niet de hele entities).

Mooi dat het nu wel werkt!

Ligt een beetje aan de scope van je project denk ik.
Ik heb zelf ondervonden dat je vaak toch je data net iets anders wilt exposen dan je entities eruit zien.
In dat geval is een DTO achtige oplossing handig, maar als het inderdaad een klein project is, zal dat overkill zijn.

[CodeCaster]

Snake schreef op maandag 14 december 2009 @ 15:35:
En waarom zou ik ze niet exposen? Het is alleen maar voor read only (wat images met wat data). Enkel de changes worden teruggestuurd (niet de hele entities).

Waarom schrijf je in je service dan niet een operation GetModel, met als returntype Namespace.Models.ModelInterface? Ik begrijp even niet waarom je een klasse zou willen publiceren zonder methode die die klasse gebruikt.

[Snake]

CodeCaster schreef op maandag 14 december 2009 @ 16:08:
[...]

Waarom schrijf je in je service dan niet een operation GetModel, met als returntype Namespace.Models.ModelInterface? Ik begrijp even niet waarom je een klasse zou willen publiceren zonder methode die die klasse gebruikt.

Het gaat niet om het waarom.

Als ik een HashTable return moet ik toch zeggen tegen de WCF Service generator: generate class voor x en y. En dit gaat niet (goed) bij LINQ to SQL.

[TheNameless]

CodeCaster schreef op maandag 14 december 2009 @ 16:08:
[...]

Waarom schrijf je in je service dan niet een operation GetModel, met als returntype Namespace.Models.ModelInterface? Ik begrijp even niet waarom je een klasse zou willen publiceren zonder methode die die klasse gebruikt.

Wat als je een service maakt die een interface terug geeft en je hebt meerdere implementaties van die interface?

WCF moet toch op een-of-andere manier weten welke types je allemaal zou kunnen terug geven, zodat het deze kan serializen (anders krijg je namelijk een exception @ runtime).

[Niemand_Anders]

Snake schreef op maandag 14 december 2009 @ 15:35:
LINQ to SQL objecten hebben een parameterless constructor. En je moet de Serialization Mode van de dbml op Unidirectional zetten. Dan werkt het allemaal.

En waarom zou ik ze niet exposen? Het is alleen maar voor read only (wat images met wat data). Enkel de changes worden teruggestuurd (niet de hele entities).

Dat is een heel gevaarlijke aanname en die wordt bij ons begroet middels 'Ja hoor, daar is ie weer!'. Software welke gebruikt wordt evalueert namelijk en het is wachten tot de dag men ook via je service de images wilt kunnen updaten of zelfs toevoegen.

Als je bezig bent met een website, scheid je dan de code van de presentatie? Zo ja, waarom zoou je dan afwijken in het geval van een WCF- of web service. In beide gevallen betreft het namelijk een presentatie van jouw data naar de buiten wereld.