Aug
8
2011

WCF RIA Services EF 4.1 Scaffolding Support, WCF RIA Services Contrib, and NuGet

Two big announcements today. First, the old RiaServicesContrib.dll file has been replaced with RiaServicesContrib.EntityTools.dll and is now available as a NuGet package. The package name is RiaServicesContrib.EntityTools. Hope that is easy to remember.

The other news is that RIA Services Contrib has a new scaffolding system for EF 4.1.

Soon after WCF RIA Services support for EF 4.1 was released, Rudi Larno released a scaffolding system for building the DomainServices based on the EF model. Unfortunatly, Rudi doesn't have time to maintain what he built so I am taking it over for him. Today I added the scaffolding code to the RIA Services Contrib project on Codeplex and published it on NuGet.

The scaffold is not exactly the same as what Rudi was using. When you create a DomainService using the scaffold you may need to add a new using statement with the namespace where your POCO entities are. Also, I modified what is generated to match the snippet code supplied by Microsoft.

To install the scaffolder

1) In the Package Manager Console select the package that will contain the DomainService
2) Type Install-Package RIAServicesContrib.EntityFramework.Scaffolding and push enter

To use the scaffolding system, in the PackageManagerConsole type in the following command line:

Scaffold RiaContribEfDomainService <TEntity> <TDbContext> <TDomainService>

So, if you are adding the Customer entity from the OrderEntities DbContext and you are creating the OrderDomainService you would type

Scaffold RiaContribEfDomainService Customer OrderEntities OrderDomainService

 

 

Jun
30
2011

WCF RIA Services support for EF 4.1 and Snippets

WCF RIA Services now has support for EF 4.1. Varun Puranik and Jeff Handley have details on their blogs about how to use it.

One of the really interesting things Varun provides is a snippet to help setup the DbDomainService since the Wizard will not be available until SP2 is released. After using the snippet I am not sure what we all did without it.

To help make it even better, I have made my own modifications and, since Varun released the original under MS-PL, I am adding the snippets to RIA Services Contrib. For now they are available at the bottom of this post.

I actually have six different snippets for both VB and CS covering both DbDomainService and LinqToEntitiesDomainService.

The six snippets are:

  • dbcrud : Code snippet for DbDomainService CRUD Methods
  • dbcrudt : Code snippet for DbDomainService CRUD Methods With Timestamp
  • dbnu : Code snippet for a DbDomainService Named Update Method
  • ltecrud : Code snippet for LinqToEntitiesDomainService CRUD Methods
  • ltecrudt : Code snippet for LinqToEntitiesDomainService CRUD Methods With Timestamp
  • ltenu : Code snippet for a LinqToEntitiesDomainService Named Update Method

 

RiaServicesContribSnippets.zip (3.78 kb)

May
4
2011

MEFing up RIA Services Part 2: Kyle's Turn

Last week Kyle McClellan from the WCF RIA Services team at Microsoft posted his own version of the Book Club sample. Not wanting Kyle to be left out, I decided to MEF up his code as well.

Here is the result:

MEFedUpRIAServicesMVVM_V2.zip (3.27 mb)

I think Kyle is doing some really interesting things with this code, but I think I prefer how John's original code used ObservableCollections (which were really EntityLists) instead of how Kyle is casting everything to IEnumerable or ICollection. What I will be creating next is my version of the Book Club which will be a mix of John's code, Kyle's code, and some completely different concepts that I am working on.

Apr
13
2011

The State of the Blog: Please Welcome HTML and JQuery to the Party

Since this blog first opened in June of 2009 it has been named The Elephant and the Silverlight. The name came from John Godfrey Saxe’s The Blind Men and the Elephant. At the time, WCF RIA Services was all about Silverlight and people were arguing about just what WCF RIA Services and Silverlight were. The name made sense at the time.

However, this blog has really always been about WCF RIA Services, Silverlight was just along for the ride. Here in 2011, WCF RIA services isn’t just about Silverlight anymore. With the release of RIA/JS, HTML is joining Silverlight as a fully functional client of WCF RIA Services. While I am still primarily a Silverlight programmer, I will be expanding my coverage and my community support efforts to include the HTML platform. So, the name of this blog is changing to just The RIA Services Blog to reflect the new platform agnostic approach I will be taking around here.

So, to the HTML JQuery programmers out there, welcome to my blog. Please cut me some slack, it will take me a little while to get fully up to speed on this whole JQuery thing but I am eager to learn.

To my fellow Silverlight developers, don’t worry I am not going anywhere. I still strongly believe in Silverlight and most of my development efforts will continue to be in the Silverlight space. I think there is an opportunity with RIA/JS for us Silverlight developers to show how easy it would be to create fallback HTML versions of our Silverlight applications so that we can get the best of both worlds. Silverlight for the platforms that support it, and HTML for the platforms that don’t. With tools like RIA/JS, maybe this dual approach will not mean actually writing the application twice.

Mar
21
2011

MEFing up John Papa’s MVVM code from Firestarter

Back on December 2, 2010 John Papa gifted the community with an excellent example of proper Silverlight architecture and I have been recommending people watch the video, download John’s code, and follow the pattern to create their own applications.

Over the last couple of weeks I have started a new project at work and this time I have decided to follow the example I have given to others. This experience is showing some places where my own preferences diverge from John’s so I have decided to share my changes with the community. I am taking the experiences in my own project and porting them into John’s project. I am not going to dump all of my changes in at once, I am going to be making gradual changes across at least three blog posts. In this first post I will be integrating Marlon Grech’s MEFedMVVM library into John’s code. Over the new two blog posts I will be changing the DataServices to use ICollectionView instead of EntityList and in the third post I will be changing the design time DataServices to use the actual RIA Servics entities instead of separate design time entities. Kyle McClellan on the RIA Services team at Microsoft has come up with something better then what I was working on for parts 2 and 3. Check it out at http://blogs.msdn.com/b/kylemc/archive/2011/04/29/mvvm-pattern-for-ria-services.aspx. I will be posting up a MEFed up version of Kyle's project.

MEFing up the code

Out with the old

I am going to be gutting John’s provider and locator code to replace them with MEFedMVVM replacements. This means that I first deleted the following classes:

  • Assets\ObjectResourceDictionary
  • DesignServices\DesignServiceConductor
  • Services\ServiceProvider
  • Services\ServiceProviderBase
  • ViewModels\ViewModelLocator

Then I removed the following line from the App.xaml

<ResourceDictionary Source="Assets/ObjectResourceDictionary.xaml"/>

MEFing up the views

Now I was ready to put MEFedMVVM into place. First I coped MEFedMVVM.SL.dll into the Lib directory of the project and added a reference. Then I needed to add MEF itself which is done by referencing System.ComponentModel.Composition

Next, BookView.xaml, CheckoutView.xaml, and EditBookWindow.xaml need the meffed namespace registered:

xmlns:meffed="http:\\www.codeplex.com\MEFedMVVM"

 

Then in BookView.xaml and EditBookWindow.xaml John’s original locator code was replaced with:

meffed:ViewModelLocator.SharedViewModel="Book"

In CheckoutView.xaml the locator code was replaced with:

meffed:ViewModelLocator.NonSharedViewModel="Checkout"

The use of SharedViewModel and NonSharedViewModel mirrors the original design that John used. BookView.xaml and EditBookWindow.xaml will share the same instance of the ViewModel while CheckOutView.xaml will get a new instance of its ViewModel every time it loads.

MEFing up the ViewModels

I registered the BookViewModel with MEF using the MEFedMVVM ExportViewModel attribute

    [ExportViewModel("Book")]
    public class BookViewModel : ViewModel

then I decorated the constructor:

[ImportingConstructor]
public BookViewModel(IPageConductor pageConductor,IBookDataService bookDataService)

CheckoutViewModel was edited the same way:

[ExportViewModel("Checkout")]
public class BookViewModel : ViewModel
public CheckoutViewModel(IPageConductor pageConductor,IBookDataService bookDataService)

MEFing up the DataServices and PageConductors

Last step was registering the DataServices and PageConductors. These were registered with MEF using MEFedMVVM’s RegisterService attribute which allows us to set a ServiceType of Runtime, DesignTime, or Both. By registering the DesignBookDataService and the DesignPageConductor as having a ServiceType of DesignTime we will get the same design time data support that John had in the original version.

[ExportService(ServiceType.DesignTime, typeof(IBookDataService))]
public class DesignBookDataService : IBookDataService
[ExportService(ServiceType.DesignTime, typeof(IPageConductor))]
public class DesignPageConductor : IPageConductor
[ExportService(ServiceType.Runtime, typeof(IBookDataService))]
public class BookDataService : IBookDataService
[ExportService(ServiceType.Runtime, typeof(IPageConductor))]
public class PageConductor : IPageConductor

 

Conclusion

I think the MEFedMVVM way of doing things is both simpler and more powerful than John’s original method. It greatly reduces the amount of classes needed and makes it much easier to add new Views, ViewModels, and DataServices to your solution. Here is the ZIP file containing the modified solution:

MEFedUpRIAServicesMVVM.zip (6.56 mb)

Jan
3
2011

How to Project in WCF RIA Services While Staying IQueryable

Updated 2/4/2011 - The blog code showed a technique using the IncludeAttribute that turned out not to work. A new technique is now shown.

A common question on the forums has been how to use project into POCO objects which are derived from one or more server side entity objects while still being able to query client side against the fields that are not being projected. These discussions usually start with people trying to use the Invoke to load data or discovering that the Query methods do not allow complex objects to be passed in. I have come up with a solution that makes the projected POCO completely IQueryable without having to play games with the Invoke passing parameters to the Query method as XML.


First, I am going to start with the database and Model from John Papa’s MVVM example at Firestarter. We have three entities that look like this:

image
 
For performance reasons, we want to create a new POCO object named MemberCheckout which is a projection of these three tables. MemberCheckout has to be a strongly typed object as WCF RIA Services does not support anonymous typed.

public class MemberCheckout
{
    [Key]
    public int CheckoutID { get; set; }
    public string MemberName { get; set; }
    public DateTime CheckoutDate { get; set; }
    public string Title { get; set; }
}

We would then add a new Query to the DomainService to load MemberCheckout (the Dummy method will be explained later):

public IQueryable<MemberCheckout> GetMemberCheckouts()
{
    var query = from checkout in ObjectContext.Checkouts
                orderby checkout.CheckoutDate descending
                select (new MemberCheckout()  
                {
                    CheckoutID = checkout.CheckoutID, 
                    Checkout = checkout, 
                    MemberName = checkout.Member.MemberName,
                    CheckoutDate = checkout.CheckoutDate, 
                    Title = checkout.Book.Title
                });
    return query;
}
public IQueryable<Checkout> GetCheckoutsDummy()
{
    throw new NotSupportedException("Dummy loads cannot be called.")
}

The question is, how do we filter MemberCheckout on a value that is not in MemberCheckout itself? For example, what if I want to to query for MemberCheckout objects where a book was published on a particular day. The answer is, if we associate our MemberCheckout object back to the entities that it was projected from then we will be able to query against them. First, we need to modify the MemberCheckout POCO to have a link to the original model.
The original POCO already has the CheckoutID field as it was a natural key for the derived POCO. If the POCO does not already have a key that exists in the original model then you will need to add one. The new MemberCheckout will look like this:


public class MemberCheckout
{
    [Key]
    public int CheckoutID { get; set; }
    [Association("MemberCheckout_Checkout", "CheckoutID", "CheckoutID")]
    public Checkout Checkout { get; set; }
    public string MemberName { get; set; }
    public DateTime CheckoutDate { get; set; }
    public string Title { get; set; }
}

Notice that the only real change was the addition of the Checkout field and an AssociationAttribute. I usually recommend having an Association set on both sides of an association but that recommendation does not apply in this case.

Next is the tricky part, we also need to make sure that the related tables that we want to query have been generated client side. If the DomainService you are using already has query methods for the related tables you want to query against then nothing more should need to be done and you will not need the GetCheckoutsDummy method. However, if you do not have query methods for the related tables then you will need to add dummy ones that do not actually work but will cause the entitiy to be generated client side. In the original version of this blog I included an alternate method using an Include. That does not work and the POCO object should not have an Include on the association attribute unless you want the associated object to be sent to the client. If the entity loaded through the Dummy method has IncludeAttributes on associations that reach the other entities that you want to query against then only the single Dummy query will be needed. Otherwise, you will need multiple dummies. With all of that setup complete, we can now write queries client side that query against the full model. For example, I executed this load client side:

var qry = from m in Context.GetMemberCheckoutsQuery()
                      where m.Checkout.Book.PublishDate == new DateTime(2009, 2, 3)
                      select m;
Context.Load(qry, false).Completed += new EventHandler(TestLoad_Completed);

The result was a single entity and when I checked what was actually executing on the SQL Server I found that the query had correctly flowed all of the way back to the SQL Server.

Dec
8
2010

Recording of WCF RIA Services Campfire

The recording of the WCF RIA Services Campfire is now available for download here. I suggest right clicking the link and doing a save as.

Thanks again to everyone who participated, and to my friends at Radical Thinking who are hosting the download.

Nov
12
2010

After Silverlight Firestarter: WCF RIA Services Campfire

The Silverlight Firestarter is coming up on December 2nd and I have decided to create a new online event, the WCF RIA Services Campfire. The Campfire event will be on December 3rd at 10:00 CST (16:00 GMT).

What is the WCF RIA Services Campire? No slides, no planned demos, just an open forum to talk about WCF RIA Services. To allow this event to be worldwide, I am hosting it through Office Live Meeting. If you are unable to connect to Office Live Meeting's audio features, please let me know what alternate method you want to use. I can probably support adding people through other methods including Skype.

The best thing about events like MIX, Firestarter, and PDC is always the common room where conversations happen. With the campfire event, I am going to try and bring that experience to everyone even if we can't all get together in person.

You can register for the WCF RIA Services Campfire event at https://www.livemeeting.com/lrs/0000000379_116/Registration.aspx?pageName=vdnb1vhrq781tk51

Oct
24
2010

The Future of Silverlight

There are a lot of questions being asked about where Silveright is going, and what is it for. Microsoft has been giving pretty straight answers on the future of Silverlight but there has been a lack of quality reporting on those answers. For example, when Steve Ballmer was recently asked about HTML 5 and Silverlight his answer was that Silverlight started off as a cross-browser, cross-technology [for making websites] but that it has been repurposed as a [cross-browser, cross-technology] platform for creating client applications. This was transformed by Network World into Ballmer saying that he "sees Silverlight as useful for adding multimedia to client apps" and they also put a description on the article saying that Ballmer was commenting on the "near death of Silverlight." It is no wonder that people are confused, perfectly good and straighforward answers are being transformed into meaningless FUD by the media.

With Ballmer's actual response (which you can see at the link above), the Gu's recent video with John Papa, and the Silverlight's teams on Future of Silverlight blog post, I think the answers from Microsoft have been very clear on where Silverlight is going. However, I know there is still some confusion and people want a simple answer. So, I am going to try and condense this down to a simple graphic:

 

By traditional application I mean line of business applications and other applications that in the past would have written using Windows Forms or WPF. I know some of my WPF friends will take exception to this, but WPF is simply not positioned to expand from the Windows PC onto other platforms where applications are needed.

By "Universal Web Applications" I mean web sites that are supposed to reach as large of an audience as possible. This covers the vast majority of the web and includes everything from shopping sites (Amazon.com) to corporate sites (Microsoft.com)

With the last category, Advanced Web Pages and Multimedia, I am covering sites that are giving up universal reach for supporting features and capabilitites that plain HTML5 simply can't offer. Here we cover NBC's Olympic coverage, NBC's NFL Football coverage, Netflix, and anything else where just the ability to display video is not enough. I hope that we will see more tooling from Microsoft in the future to make it easier to these types of web application to a plain HTML 5 experience for platforms that do not have a Silverlight client.

 Finally, let me close this out with some of my own commentary on the subject of Flash and Silverlight vs HTML 5. I think that it is important that Silverlight and Flash continue to break new ground. HTML 5 is currently adding features that Flash (and more recently Silverlight) pioneered. I think you can make a very persuasive argument that HTML 5 only exists because Flash was there first. Who knows what new abilities will be in HTML 6 that will be pioneered in current and future versions of Flash and Silverlight? The experience with the Java has taught us that innovation will not be allowed inside the standards process, at least not by Microsoft. It is better that Microsoft and Adobe have their own sandboxes outside of the "open standards" where that innovation can occur.

Jun
1
2010

WCF RIA Services Speculation: EntityCollectionView

Disclaimer:
I am not a Microsoft employee, I have not even played a Microsoft employee on television. What follows is my own ideas on a what part of a future version of WCF RIA Services could look like.

What we know


As of this writing, MVVM friendly DomainDataSource is the fifth most requested feature for the next version of WCF RIA Services. According to Jeff Handley, this is what he envisions for this feature:

    What I have been imagining is taking the existing DomainDataSource feature and splitting it up into a set of components that can be used selectively from a ViewModel, or used all together as the DomainDataSource control that you know.
    The PagedEntityCollectionView class would likely become public, as well as the EntityCollectionView. I'd also like to break the data loading functions out so that the logic used to submit the requests for loads and the response handling could be utilized from a ViewModel. The DomainDataSource manages situations such as hierarchical data and there's a lot of code involved to replicate that in a ViewModel--I'd love to see those functions exposed for easy consumption without using the DomainDataSource control in the UI.
    So I really see this item as a way to get the features of the DomainDataSource out of the DomainDataSource, and available to developers to use how they wish."

Why this matters

Over the last two posts, I have been discussing ways that a ViewModel could present collection of Entities to the View. Of the options I presented only the PagedCollectionView is acceptable to me in the short term but in the long term there clearly has to be a better way. The other option which I hadn't previously mentioned is to build something new from scratch, an option that I have contemplated myself. The reason that I haven't is that I do not like duplicating logic that already exists and the fact that the PagedCollectionView and the EntityCollectionView already exist make me unlikely to want to write my own ICollectionView from scratch. To me, the best solution is to get the public EntityCollectionView that some of us have been talking about for a year now.

EntityCollectionView? What is that?


Outside of a few old blog entries from Jeff and Brad you probably haven't heard of the EntityCollectionView. The EntityCollectionView is everything that the PagedCollectionView isn't. It is strongly typed, it supports the Entity, it supports IEditableCollectionView against an EntitySet, it supports external delegates to implement adds, removes, and deletes, and finally there is a PagedEntityCollectionView that adds RIA Services integrated paging support. Unfortunately, the current EntityCollectionView is internal and can only be used by the DomainDataSource. It will take lots of time to properly refactor the DDS and get all of the interfaces fully implemented, time that simply didn't exist for the initial release of RIA Services. Anyone who has been following the development of RIA Services knows the DomainDataSource was probably the most actively modified component of RIA Services right up to the end. They would also know that the DomainDataSource also the most monolithic parts of RIA Services.
What we can gather from Jeff's above statement is that he wants to refactor the DomainDataSource to better match the rest of RIA Services itself. That means being more modular and being more programmer driven. For the rest of this post, I am going to discuss some scenarios that I think should be covered by the new classes:

EntityQuery support


In the previous post I had a link to an overview of the ICollectionView. One of the issues with most implementations of ICollectionView is that sorting is slow due to reflection issues. Another issue that is specific to RIA Services is that for loading data we have the EntityQuery but for the ICollectionView we have the Filter and the SortDescriptions. Having two different methods of doing the same thing would be annoying. What would be better is the ability to supply the EntityQuery to the EntityCollectionView. This would allow the same EntityQuery to be used for the load and the filter.
The unknown here is if the ICollectionView.Filter and ICollectionView.SortDescriptions should still be implemented or not. The SortDescriptions could probably be derived from the EntityQuery (and the reverse) but the Filter is tricky.

Read Only Mode and user providable methods for insert and delete

The ViewModel needs to be the owner of the EntityCollectionView and control of insert, deleting, and paging. In many cases, the EntityCollectionView can be left to default functionality but in others the ViewModel needs to provide the actual logic. A good example of this would be to look at how the EntityCollection is implemented in your generated code. That shows an example of how add and delete logic can be externally supplied.
Unfortunately, this does mean that the constructor for the EntityCollectionView may end up being rather complex. It is possible that some kind of "controller" object may be needed that can be supplied during construction and held onto by the ViewModel.

Strongly Typed


One of the biggest problems with the PagedCollectionView is that it is not strongly typed. The problem here is that there may be other logic within the ViewModel that wants to use the same CollectionView that the View itself is seeing. Without strong typing, this requires lots of type casting which is, at best, annoying.

Paging


Yes, the need for paging is obvious, but it also important to keep in mind the type of paging that is needed. It is possible that in some situations that the paging is being done only against already loaded entities. Much like with the update and the delete, we need to be able to override the paging so that the ViewModel can override.

Conclusion


This has been an interested three part series for me as it helped clarify some ideas that I have had for awhile. For this post in particular, if you have any scenarios that you think the EntityCollectionView needs to cover please let me know and I will see if I can modify the post to account for it.

Month List