Survey: How Do You Use the DomainService Wizard?

I need to ask a favor of all my regular readers out there (*crickets*). I often hear stories along the lines of “I use the DomainService Wizard to generate my DomainService. Then I make tiny changes to the generated code or metadata and may move it or split it into separate files. Later, when I update my database, I re-run the DomainService Wizard to re-generate my DomainService and manually merge the newly generated service with the old one.”

So my question is this: “What problem are you solving?”

I think we can all admit any solution where one of the steps is “manually merge” is sub-optimal. This is something I want to fix. If you’ll oblige me, I’d love to hear what you’re doing and why you’re doing it (as a bonus, responding to this post makes it much more likely I’ll address your scenario).

Feel free to add a short comment with your thoughts or email me directly. Thanks.

Comments (18)

  1. Lily Qian says:

    I saw this a couple of times: The metadata class is NOT generated even I check "Generate associated classes for metadata".

  2. Colin Blair says:

    LOL, my vote is to remove the wizard completely.

    (Really? No. But now I get to tweet about it.)

  3. kakone says:

    – How Do You Use the DomainService Wizard?

    As many people, I don't use it ! I vote also to remove this wizard 🙂

  4. TheJet says:

    We frequently re-gen the domain service during our initial sprints.  This is largely because we have an active client and service layer that's changing frequently, and the domain service does not automatically do things like include EF4 navigation properties in the data sent to the client, so we have to customize the metadata by hand.  I outlined the process we [still] use internally during the 'stabilization phase' of a project in a blog post last year:…/WCF-RIA-Services-Regeneration-Can-we-get-a-better-story-please.aspx

    Really, I would be pretty happy with a situation where you basically choose between a completely auto-generated template, and then maybe something along the lines of a set of T4 templates that you could customize to generate 'your' version of the RIA services code.

    Additionally, flags that allowed the metadata to be split into distinct files per class [with a destination folder], a 'force generate' option which would regenerate all metadata files [to avoid having to exclude the metadata prior to generation], along with an option to automatically do things like 'Include' child navigation properties in the returned result would be hugely helpful.

    Even going so far as to have a configuration file type approach that you could alter and then have the code regenerated as something between T4 and re-running the wizard could be useful in certain scenarios.

  5. Ward Bell says:

    I  don't use the wizard. But then I don't use RIA Services <chuckle/>. Seriously, as long as you folks make writing all that boilerplate necessary for even the most mundate class CRUD, you're going to be stuck in sand. The problem isn't the wizard. The problem is that the wizard feels necessary because to write the code by hand is so painful.

  6. kylemc says:


    That's a great post. Thanks.


    Thanks guys. I hope to pleasantly surprise you in the next iteration.

  7. Colin Blair says:

    @TheJet There are T4 templates in RIA Services Contrib. I am sure Kyle would be as interested as I am in finding out what you think about them.…/64147

  8. rpk1963 says:

    Don't use it.

  9. I think the wizard is great to get starting with a new domain service.

    I've the following three suggestions to improve the wizard for using it with existing domain services:

    1) It should generate partial classes. This makes it easier to combine the generated domain service operations with hand-written ones.

    2) It should generate the CRUD operations in a separate file per entity type. This improves the maintainability of the domain service when the number of entities is large.

    3) It should detect for which entities CRUD operations already exist and only extend the domain service with CRUD operations for new entities. This is to support generating new CRUD operations for new entities while not interfering with (manually adapted) exiting CRUD operations.

  10. weitzhandler says:

    1) I think The wizard should be able to be ran again when clicking on the DomainService file, or even in the code (like in ASP.NET MVC – Generate View).

    So I should be able to add some classes to the generation.

    2) Be more flexible with porting types between the various DomainContext (for example I have a User class that inherits Contact, I want to  expose it in another DomainContext but that's impossible).

  11. Moorster says:

    I use the Wizard to create the initial DomainService. Then I try to keep it in sync with the DB manually by making small changes. After a while I start to wonder if I have all the changes. Eventually I just delete and re-create the DomainService from the wizard.

    If I have custom code/queries I try to keep those in a separate partial class that I maintain so that they are not lost when I re-create the DomainService.

  12. Moorster says:

    I really like the wizard and I think it's very handy. I just wish there was a way to re-sync with the EF. The EF, after all, has the ability to re-sync with the database.

    While you're at it, I have another request. There needs to be a "Select All" button in the wizard when choosing the tables to include. I often have over 30 tables and checking each one, plus checkig the "editable" check box for each one, get tedious. It is made worse by the fact that you have to do that every time you re-generate the DomainService because there is no re-sync option.

  13. Eric says:

    @moorster if you ctrl-A from within the window it will highlight all the rows, then click the top editable button and the tables and editable will be selected.

  14. Jason Rosenthal says:

    Don't kill the wizard!  

    I'm using it for all basic CRUD stuff.  I put all custom queries in a separate file so I can delete the service and then add it again to pick up all the database schema changes.   I don't care for how the metadata is currently being done because I haven't found a trick for it.  

    It would be nice to be able to make runtime function calls to merge the mountain of metadata I've been adding to the existing entity stuff that is part of the ER.   I think someone on codeplex has tried something like that but it doesn't work with custom attributes.   Keeping the metadata classes matching the ER manually has been tedious and error prone for me.  I might remember to make 87 or so changes out of the 91 that were made during a typical schema update.  Visual Studio run out of error message lines until I find the last change.  I try to do it when no one is around to see the screen.

    What would really be cool is a domain service designer with a full gui for adding your metadata and other domain service stuff.  It’s hard to visualise the service with all of its projections right now.  Schema updates could work similar to the way Entity Data Model does it; instead of updating from database, you are updating from models.  Bonus marks for being able to remap field name changes before merging everything.   You may even consider a query designer for linq, that feature seems to have gone missing since the dataset era.

  15. Mark says:

    This wizard checks for existing information in respect to adding business objects and properties and if it finds any it seems to abort this process.  What I do when I update using the wizard is copy the metadata information out to a seperate text file.  Then I run the wizard and create the metadata in a new DomainService file.  Then I manually compare.

    I think a step forward in the wizard would be to append existing business object information and marking it as such … perhaps with a date and time of addition like:


    Appenede to Object: busObjName on Apr. 1 2010






    End append


    I think the process not proving any feedback in respect to not creating metadata information leaves many people confused as to what has or hasn't happened.

  16. duluca says:

    There really needs to be an "Update Domain Service Wizard", which can destructively or non-destructively update an already generated DomainService class from the Entity Model.

  17. Sam Wheat says:

    Thanks for asking Kyle!  My problem with the current domain service wizard is that it is not useful when there are a large number of tables (50+).  Here are my suggestions:

    1.) Don't listen to Colin Blair. 😛

    2.) Output one file per entity.  Most important in my opinion.

    3.) Prompt for a directory to output the files to.

    4.) One service class is generated, each file is a partial of that class

    5.) Don't overwrite a file of (entityname) if it exists.

    6.) Regarding metadata, that belongs in the EF, not much you can do about regenerating that.  I'm looking forward to the day when I don't ever open SQL server manager to modify my tables, sp's etc.  I want to work entirely from the EF interface.

    See this post:…/224371.aspx

  18. kylemc says:

    Thanks for all the feedback. We'll definitely look over everything here when deciding which updates we should make in the future. You guys are great.

Skip to main content