LS 4 - shared model or separate dto assembly?

hi again,

sorry if this has already been covered in the forums - have done a search but can't find anything relevent.

Our current project (LS 3.1) I'm generating our dtos via T4 templates in a different project.  So we end up with a standard WCF Blah.Contracts.Data assembly. 

My very limited understanding so far (based off your LS4 intro blog post and the sample I found in a forum thread) is that it looks like the intention is to generate the WCF attributes on the model entities - so they can be directly serialized over the wire, rather than creating entirely separate dtos.  yes?

So that feels really strange to me - the model contains all this business logic and domain knowledge and normally that would not be exposed to the client.  If service consumers can rummage through the implementation of the services (via the model assembly) then there is the danger that they'll code the client with that in mind - making assumptions that could be broken if I change the implementation of the service.

Is there a way in LS4 to maintain the previous pattern of exposing only separate dtos and mapping these to entities within the service boundary - so service clients just call coarse-grained operations without knowledge of the implementation. 

Or do you envisage something different in the way clients interact with the model in LS4?  Are you deliberately trying to blur the explicit service boundary by sharing the model at both ends? From the sample, it looks very much like the client is happily throwing around and newing up entities, querying the distributed unit of work as if there isn't a service boundary at all.  There are a couple of old-skool service methods but it doesn't look like the client is using them - it just uses the distr unit of work.  I can see how it's pretty cool being able to just fling entities around in the client and have them auto-persist across the wire and perform serverside without having to think about it but I don't think I need that just yet. 

I'm not against changing the patterns of how we do things, it's just that allowing the model to exist on the client without an explicit dto layer in between is not how we've typically done things in the past and it would be helpful to hear a bit more of your rationale...  If I don't want a lot of upgrade work for LS4 (altering how existing clients work) I do need standalone dtos to be generated.  Please.

So in short - it would make the transition way easier if I could get the LS4 model to a) generate separate dtos and b) generate them in a separate assembly. Is this possible?

thanks

Hi Justin,

There is actually improved support for 3 scenarios in 4.0, the first of which is what you are thinking of with the shared model assemblies using the DistributedUnitOfWork. You can think of this as being similar to remoting in that you simply work with a UnitOfWork and your model at the client and entities are queries and persisted back to a service endpoint. The main difference being its all WCF based.

The other two scenarios are for DTOs or where you have a custom WCF service where you want to expose entities and have them serialized. The use of DataContract attributes is needed for the scenarios where the entities are being serialized. If you just want to use DTOs then you can certainly go ahead and do that!

In general I would favor a DTO based approach as well by default, although where you have a private client/service where its of benefit to share the model that the DistributedUnitOfWork can be quite advantageous because you can avoid having to generate a bunch of extra code.

So to answer your question, yes its absolutely supported in LightSpeed 4 to go for a DTO based approach. If you are generating your own DTOs then you can code these however it makes sense, either in a seperate assembly if they are being shared between the two parties, or just at the service if your clients will be generating their own versions based on metadata. You may have noticed that in 3.x we included some templating support for auto-generating DTOs. We have decided to keep this in 4.0, but we will be turning it off by default using a compiler conditional (at least thats the current plan, its yet to be finalized since we just recently decided on what we were going to do with that).

In terms of working with your DTOs, we have included an additional method on the UnitOfWork which will help with reconciling your incoming DTOs with the entities which they would be mapped to which is the IUnitOfWork.Import() method. Its described more in the blog post: http://www.mindscapehq.com/blog/index.php/2011/03/08/dtos-and-pocos-in-lightspeed-4/

So in summary its fair to say we are not particularly pushing one approach over the other, rather we have tried to do as good a job as possible for now at improving the assistance we can give people regardless of the scenario they might end up with. I guess the bulk of the work appears on the DistributedUnitOfWork side since that all had to be created fresh, but we are equally interested in all 3 approaches :)

The easiest transition would be if you used DTOs now, and simply upgraded. Functionally nothing will change unless if you are using the code generated DTOs in which case you will likely just have to include a compiler conditional in your model project to re-activate them. After that you can then look at if the .Import method makes sense and take advantage of it if it does.

Hope that helps, but please fire back any follow up questions..

Jeremy

ok, makes sense.

I would love to ditch my t4 templates and use dtos generated off the model.

the reason i created my own dto generation templates was because the LS-generated dtos (i *think* the ones i initially tried using were in v3.x) didn't have everything i needed on them - and because i wanted the dtos in a separate assembly.

the new datacontract generation stuff looks like it's exactly what i want - "generate backreference id", etc. And i'll definitely use the IUnitOfWork.Import method - good stuff.

[quote user="jeremy"]we will be turning it off by default [/quote]

so how do i tell the model to generate the dtos?  what's the magical compiler conditional?  and how do i get it to generate the dtos in another project?  i guess i could always get the dtos generated into the model project and use VS linked files to surface them into a separate dtos project...?

cheers

At the moment all of that is disabled still and isnt even in the templates, so for now you can hack it back in by copying over a DataContracts.vm from 3.x and adding back in the use of it into Base.vm.

Alternatively it will be added back in with the compiler conditional (again, thats just based on our most recent discussions) over the next week or so (pure speculation on my part since Ivan is tasked with this..)

Keep in mind that the Designer properties are strictly for the entity DataContract annotation at the moment, but thats a very good idea to extend it to the DTO generation if feasible. Ill note that one down but for now our plan is just to port over the same templates as was in 3.x.

Jeremy

ok, that all makes sense thanks.

couple of comments and then i'll leave you alone:

• having separate dtos and exposing only these (and not the actual entity types themselves) across a service boundary has long been regarded a best practice.  Though I can see cases where I would want the ability to perform transparent remoting (sort of CSLA style), for me the primary use case will remain separate dtos generated off entities.  Whatever you guys can do to make that better/easier is good by me.
• in that vein, would you consider porting your vm templates over to T4?
• was thinking last night - actually, generating dtos in the model project and exposing these through a Contracts.Data project via VS linked files is a stupid idea.  You'd end up with resharper always asking you to resolve which of the two equivalently named dto types you want to use.  So I think (?) the most uncomplicated way is to use T4 templates which refer back to the model in another project, like I've done already.  Have I asked you whether you've considered porting your vm templates over to T4?!
• it would be very cool if you could tell the model generator about a dependent t4 template.  At the moment I have to remember to regen T4 after saving model changes - would be nice if it did this automatically, like the nvelocity templates.
• I haven't looked into this _at all_ but I was wondering if it's possible to use Mindscape.LightSpeed.MetaData as the source for templates.  At the moment it's a bit voodoo trolling around in Reflector for Mindscape.LightSpeed.Generator.Integration.Dsl, trying to work out how to query/where on earth to find specific metadata for entity types.  If I could fire up an EntityInfo for each type then presumably it would be fairly easy to develop/modify templates from entity metatadata?  And ideally those swish new designer datacontract annotations would be available in the Mindscape.LightSpeed.MetaData assembly and easily accessible from T4 templates.  You guys could even give us a bit of a quickstart - have you considered porting your vm templates over to T4 and using Mindscape.LightSpeed.MetaData?  :)

i think that's all i have now, thanks!

Yep we can have a think about the T4 template support. Ill have to discuss this a bit more with Ivan to understand whats involved since he is the Lord of the Designer.

In regards to use the MetaData library for subsequent code generation, yes you could certainly derive a lot of the same information that goes into building up the templates by using this. You would be able to get an understanding of the fields, properties and associations as these are all aspects of the entity and form part of LightSpeeds internal model, however designer specific information would have to be gleaned more from reflection or in some cases such as the ClrAttributes which have been applied to the class/properties or fields as that information is held in the .lsmodel file directly.

Jeremy