WCF RIA Services

Re: .NET RIA Services V1 CTPs: current thinking

ringi — Sat, 17 Oct 2009 19:27:08 GMT

I am not yet using Silverlight or RIA services however this is what I would like to see.

I don’t mind being limited to .NET 4 as it is unlikely many people will be using RIA before .NET 4 ships. The short term pain of having to get .NET 4 installed is worth it for the years of benefit that a better RIA will give.

I would like to see match better support for NHibernate including examples. I don’t wish to have to choose between the leading ORM and the leading UI platform…

I would like to see support for WPF, encase I have to switch from Silverlight to WPF at some point.

Having a system like Aps.net dynamic data to generate the 101 simple data admin forms any reel applicant needs would be of great value. (Otherwise part of an application may need to be Asp.net just to use Aps.net dynamic data) However don’t delay version 1 for this.

Re: .NET RIA Services V1 CTPs: current thinking

nigelpage — Thu, 15 Oct 2009 03:01:20 GMT

We would like to be able to use the DomainSevice with anything we like and are happy to build adapters if required. Our current needs are: -

WCF integration
ASP.NET MVC integration

We have a current WCF service layer that is used for app integration and need to maintain that, as well as not wanting to duplicate functionality on the server side, so settling on DomainService would be very advantageous. Our current UI standard is WPF, but our intent is to move it all to Silverlight. When we started development Silverlight could not support what we needed, but that is no longer true, so we will take advantage of it.

We also need to be able to expose 'snippets' of functionality embedded in ASP.NET MVC pages, so out of the box integration is also important to us.

Quite frankly, the more plumbing you provide, the less we have to provide, so flexibility on server side usage of DomainSevice is important to us.

Regards,

Nigel

Re: .NET RIA Services V1 CTPs: current thinking

Casimodo72 — Thu, 08 Oct 2009 14:04:33 GMT

Regarding MVVM:

Jeff Handley's EntityCollectionView seems to work with EntityList and EntityCollection, while Brad Abrams' version does not have support for EntityCollection. Could it be made to work on an interface instead?

Would be great if Jeff Handley could also expose something like the (internal to DDS) DomainDataSourceEntityCollection and make the EntityCollectionView work with it. It's really handy to have a collection in between the EntityList.

Regards,

Kasimier

Re: .NET RIA Services V1 CTPs: current thinking

ColinBlair — Mon, 05 Oct 2009 18:07:42 GMT

RobertMcCarter:

An absolute MUST is the offline data story (the functionality from the attachable behaviours demonstrated by Nikhil at MIX). I'm really hoping you've got this in for the PDC beta.

Support for the M-V-VM pattern is very important

I am not sure about the attachable behavior thing, but the offline data story for RIA Services is pretty good. Taking all of the Entities in the EntityContainer, saving them to isolated storage, and then bringing them back in is pretty easy. I have code on my blog to do that. There was an official Microsoft example showing offline storage as well but it is a lot heavier.

RIA Services is really, really good at MVVM support. BradA has all of the code needed to replicate the parts of the DDS that are worthwhile in your VM code.

Re: .NET RIA Services V1 CTPs: current thinking

RobertMcCarter — Mon, 05 Oct 2009 16:59:00 GMT

It's probably too late for input, but here are my thoughts:

An absolute MUST is the offline data story (the functionality from the attachable behaviours demonstrated by Nikhil at MIX). I'm really hoping you've got this in for the PDC beta.
Support for the M-V-VM pattern is very important
I think .NET 3.5 sp1 is a must
I really don't care about EF support
I don't care about integration with ASP.NET MVC, etc...

Additionally, it would be great if the generated Silverlight classes mimicked the class hierarchy on the server side! I've designed my server-side class hierarchy very carefully and for very important reasons - having the code generator completely flatten it is very frustrating.

Thank you for the excellent work, even in preview form this is a great tool!

Robert

Re: Design suggestion for Visual Studio Domain Service extension

Casimodo72 — Tue, 15 Sep 2009 19:11:04 GMT

This sounds very good.

Regarding (3):

1) I currently cannot think of an automated way to generate attribute initializations
   without knowing exactly the internals of the attribute's type.

   a) If the attribute has a default constructor, one could generate the initialization
      with named arguments resembling all public properties (and the values of those) of the attribute.
      - This does not always work. E.g. the DisplayAttribute wants its GetShortName()
        to be called, rather than its ShortName property in order to perform a lookup on its ResourceType.

   b) If the attribute doesn't have a default constructor, thus wants positional arguments,
      then I need to know what properties at what position of the attribute should be used as positional arguments.

   c) I need to know the default values of the attribute's properties to avoid to flood the initialization
      with unneeded property setters.

   Currently I assume that a generation can only be performed when using some kind of description of the
   attribute's type, or by coding dedicated transformations for each known attribute type.

2) AFAIK, only a specific set of known attributes on the domain class are generated/regenerated on the
   client side entity and its properties.

   E.g. if I annotate my domain class or any of its properties with my new custom attribute "MyDummyAttribute",
   then this attribute will never be gerated on the entity.

3) I can have my "MyDummyAttribute" transported to the client side though using the "shared" partial classes
   (those are read-only for the generator).

So what I would need is the code you already seem to have in use for the generation
of the specific set of known attributes.
I currently don't see the need for me to extend that set - but one never knows.

Regards,
Kasimier

Re: Design suggestion for Visual Studio Domain Service extension

roncain — Mon, 14 Sep 2009 13:06:47 GMT

Casimodo72:
I dunno much about T4, but it would be great if those T4 templates could be designed...

Thanks for the suggestions. The "override specific chunks" was a fuzzy way to say what you said. We recognize most developers want to just tweak 10% (or less) and let the other 90% be handled by the default implementation. Other developers may want to swap out everything. So our challenge will be to offer extensible ways to do that. Key to that will be a well factored set of T4 templates with good extensibility built-in, operating over a simple object model over the metadata of the domain services.

From the discussions above, you can see we've also heard suggestions about respecting even the order of items in the metadata so that we don't randomize the order of entities or methods the developer may have grouped. All these factors will go into the design.

Yes, the helper classes will be part of this story -- but it will be important that even the helpers are extensible. The example #3 you gave is actually quite challenging for the general case, as you no doubt have already discovered.

At this point, one important aspect of our T4 story is hearing suggestions like yours and the ones above. All of these will help mold the design.

Ron Can

Re: Design suggestion for Visual Studio Domain Service extension

Casimodo72 — Mon, 14 Sep 2009 12:38:00 GMT

@roncain "We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template)"

I dunno much about T4, but it would be great if those T4 templates could be designed
so that one has full control over the generation process.
"let you override specific chunks" sounds a bit like the current CodeProcessor approach,
which is quite limited, since one can only post-process the CodeDom that is
always generated by default.

E.g. currently, when the a TypeDescriptionProvider is set for a domain class,
there's no way to stop the processor from applying it. All one could do is remove all the
generated attributes and apply the TypeDescriptionProvider's information a second time,
without being able to reuse any of your attribute-generating code.
I.e. the stage at which the desired custom behaviour should have
been applied, namely at attribute aquisition and merge time, is not accessible and
leads to funky hacks.

The following would be nice:

1) Let me customize standard stages in the transformation pipe.

2) Let me inject new stages (e.g. post-processing, pre-processing, etc.) freely.

3) Let me have access to a public library for doing standard stuff.
   I.e. it's nice to know that I can customize something by overriding it,
   but mostly you realize that if you just want to customize a tiny 10% of
   of a thingy, you need to reimplement the other standard 90% without
   being able to just call the standard code - because it's internal.
   E.g. I would be very thankfull for a method in the library, which generates
   an [Attribute(myPositionalArg, Name=myNamedArg)] by giving
   it an instance of an Attribute.


As already mentioned, I dunno much about T4 and cannot foresee
what is meant with "let you override specific chunks",
so this post might not apply.

Regards,
Kasimier

Need to 'reflect' on DomainContext

yashgt — Fri, 21 Aug 2009 09:40:11 GMT

Hi,

A DomainService class exposes a DomainServiceDescription object that contains the list of operations exposed by the DomainService and DomainOperationEntries. This helps frameworks like ASP .NET Dynamic Data to figure out the names of methods in the doamin service.

We are working on building something similar to Dynamic Data, but on the client side in a Silverlight application which uses RIA Domain Services. It would be useful to have the list of operations and rest of the description of the DomainContext using something like DomainContext.Description, which would emit DomainOperationEntries just as it does on the server.

Thanks,
Yash

Re: Design suggestion for Visual Studio Domain Service extension

ColinBlair — Thu, 20 Aug 2009 15:44:51 GMT

roncain:

ColinBlair:

Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help.

Interesting -- both requests for wizard extensibility are focused on what I might call "code gen extensibility", albeit at a special point in the generation process. We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template). I had not considered triggering this extensibility at the point a DomainService is generated by a wizard, but it sounds reasonable to add to the scenarios to consider.

This is great news for future versions of RIA Services. I do love T4 templates.

Re: Design suggestion for Visual Studio Domain Service extension

MichaelDBang — Thu, 20 Aug 2009 15:00:05 GMT

roncain:

To be clear, I hear 2 different code-gen needs -- the ability to T4'ize the generation of DomainServices, including during template creation. And the ability to T4'ize the generated proxy classes during a build. All I can promise is that we will add these to our code-gen-extensibility scenarios as we plan the next version.

YESSSSSSSS!!! Great to hear.

Re: Design suggestion for Visual Studio Domain Service extension

roncain — Thu, 20 Aug 2009 14:36:15 GMT

ColinBlair:

Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help.

Interesting -- both requests for wizard extensibility are focused on what I might call "code gen extensibility", albeit at a special point in the generation process. We're considering a T4 approach for the next version with a good set of extensible T4 templates (i.e. to let you override specific chunks rather than taking ownership of a single monolithic template). I had not considered triggering this extensibility at the point a DomainService is generated by a wizard, but it sounds reasonable to add to the scenarios to consider.

To be clear, I hear 2 different code-gen needs -- the ability to T4'ize the generation of DomainServices, including during template creation. And the ability to T4'ize the generated proxy classes during a build. All I can promise is that we will add these to our code-gen-extensibility scenarios as we plan the next version.

Re: Design suggestion for Visual Studio Domain Service extension

ColinBlair — Thu, 20 Aug 2009 14:18:30 GMT

yashgt:

We would like to customize the generated the Domain Service class, such that it is partial and it invokes a few partial methods that we define. We are not able to customize the Item Template at Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\1033\BusinessLogic.zip as we are not able to capture the name of the class, entity chosen ,etc. Had these been exposed as Custom Parameters in the template we could have done something there.

Adding partial to the class definition would be a very good thing, and if there was some way for the wizard to detect if the named DomainService already exists while it is checking for metadata and not generate the EnableClientAccessAttribute on the additional partial classes that would be a huge help.

I don't agree with the partial methods. You have to take ownership of the DomainService, the wizard is only generating a template for your DomainService. From a technical standpoint, anything in the wizard generated DomainService could just as easily have been done at runtime like how ADO.NET Data Services does it. The only reason that the DomainService exists the way it does is for you to make changes to it.

Re: Design suggestion for Visual Studio Domain Service extension

yashgt — Thu, 20 Aug 2009 13:57:00 GMT

Hi,

We would like to customize the generated the Domain Service class, such that it is partial and it invokes a few partial methods that we define. We are not able to customize the Item Template at Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\1033\BusinessLogic.zip as we are not able to capture the name of the class, entity chosen ,etc. Had these been exposed as Custom Parameters in the template we could have done something there.

Thanks,

Yash

Re: Design suggestion for Visual Studio Domain Service extension

roncain — Thu, 20 Aug 2009 12:18:30 GMT

yashgt:

It will be useful if this class is defined as public so that people can derive their own wizards from it and thereby control the structure of the class that gets created.

It is an interesting idea, but we're trying to minimize the public surface area we commit to support in future versions, and to minimize the Test matrix for extensibility points (imagine we unseal this class and someone undoes some project changes we assume succeeded). We've actually done some of this in house, and it can get difficult to define and test the contracts for what the wizard does.

What kinds of extensibility were you considering? Adding different references? Altering the project structure?