Freigeben über

Survey: How Do You Use the DomainService Wizard?

  • Artikel

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

  • Anonymous
    May 05, 2011
    I saw this a couple of times: The metadata class is NOT generated even I check "Generate associated classes for metadata".

  • Anonymous
    May 05, 2011
    LOL, my vote is to remove the wizard completely. (Really? No. But now I get to tweet about it.)

  • Anonymous
    May 05, 2011

  • How Do You Use the DomainService Wizard? As many people, I don't use it ! I vote also to remove this wizard :-)

  • Anonymous
    May 05, 2011
    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: blog.virtual-olympus.com/.../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.

  • Anonymous
    May 05, 2011
    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.

  • Anonymous
    May 05, 2011
    @TheJet That's a great post. Thanks. @EverybodyElse Thanks guys. I hope to pleasantly surprise you in the next iteration.

  • Anonymous
    May 05, 2011
    @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. riaservicescontrib.codeplex.com/.../64147

  • Anonymous
    May 05, 2011
    Don't use it.

  • Anonymous
    May 05, 2011
    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.
  • Anonymous
    May 07, 2011
  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).

  • Anonymous
    May 09, 2011
    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.

  • Anonymous
    May 09, 2011
    The comment has been removed

  • Anonymous
    May 09, 2011
    @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.

  • Anonymous
    May 11, 2011
    The comment has been removed

  • Anonymous
    May 11, 2011
    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

property property property

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.

  • Anonymous
    May 13, 2011
    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.

  • Anonymous
    May 18, 2011
    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. :P 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: forums.silverlight.net/.../224371.aspx

  • Anonymous
    May 24, 2011
    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.