Service Factory v3

Community Feedback for drop 19

The following answers were provided by you, the community and expert advisors. You may continue to provide responses to the questions below by sending Don an email at or leave comments on this page. We'll incorporate the feedback into the page and remove the comments (if necessary)
  • Would you like for a Service Contract model be created by default and placed in the product definition project (Boeing.Model) for you?
 I actually hate that initial Class1.cs file that is created by default. The first thing I usually do is to
 remove it right away and start from scratch. It forces you to carefully consider the appropriate name. As a
 side-note, I would not append the .Model postfix to the project name. Different architects prefer different
 kinds of naming and concepts. And moreover, you already mentioned that this project will gain additional 
 responsibilities which may not be covered by the name .Model.

 No I would rather do it manually - as you have it now

 No, I like the idea of working on the level of these two models.

  • For the operation shape, we are considering removing the "Action" property. What do you think about this? Are there other technology-agnostic properties you think should be added/removed?
 Since the action allows you to define a name that may last longer than the implementation name, I would
 leave it in. And if it’s empty and the Name property is set, automatically copy that value to the
 Action property.

 I agree with removing the Action property

 I have mixed feelings about mixing technology in both these models. I’d rather have an extra model and the
 ability to map both the service contract model and data contract model to this model. This extra model would
 add any technology specific information in this separate model. Thus service contract + data model
 <transforms into> wcf sercice contract and wcf data model <generates> wcf specific code.

  • Do you have any feedback, suggestions, or general comments about using the Service Contract Designer?
 - Provide guidance on the scope of a service diagram (how many services per diagram)
 - Allow printing of the diagram (for reviewing and communication)

 Awesome - loving it so far!!

 No, not at this point.

  • Now that you've added a couple of properties, is clicking on the elipsis and using the type selector a reasonable way to do define the Data Member types? What is the most natural experience?
 It’s great for selecting non-primitive members, but making it a drop-down box for quick-selecting
 primitive types would be great. Even better, allow entering int and automatically resolve it
 to System.Int32.

 From using VS 2005 - I find it routine and reasonable to do it using the elipsis and using the type selector

 I would like to have this option available as a dialog on top of the designer which is activated by a right
 clicking the shape and selecting a menu item.

  • Does the separation of the Service Contract designer (for service-specific things) and the Data Contract designer (for things reusable across services) make sense? Would a different separation feel more natural? Do you have any other thoughts or suggestions about using the Data Contract designer?
 - I like the separation since data contracts can be reused. 
 - Use UML-style multiplicity (1, *, 1..*)

 Yes this makes perfect sense to me

 This separation makes sense looking forward to the entity data model.

  • Now that you've completed the design of the fault contract, does the process seem natural? Do you have suggestions for improvements?
 Allow double-clicking the Type property to quickly create a new item of the appropriate type and
 wire them up (e.g. a data contract or fault contract).

 From using VS 2005 - I find it routine and reasonable to do it using the elipsis and using the type selector

 No, not at this point.

  • Does applying the technology platform at the designer level seem natural? Would you rather specify the technology on each individual shape? Do you have another suggestion?
 I would like to make the choice between ASMX or WCF at the service level. The choice between C# and
 VB is more fundamental to your projects and should be made at project creation.

 This is listed as question #6 in the Wlakthrough.htm (just a little typo since there are 2 #6's).
 This process was fairly easy and simple but, being a beginner at this, wonder if this
 could be done at the very beginning setup steps instead of at the end? May be easier
 to remember that way. BUT - other than that I like the idea of just naming it in one place
 versus on each individual shape.

 No. Same mixed feelings I conveyed in question 2

And the last one:
  • It is very likely we will not be able to:
    • Ship a single release that works on both VS 2005 (Whidbey) and VS 2007 (Orcas). This probably won't be possible for technical reasons.
    • Ship 2 releases: one for 2005 and one for 2007. This is just way to costly for our team(time and money).

So, with that in mind, knowing we will ship on November 15th (approximately a month after 2007 is released), what version of VS would you prefer the final release support? If your answer is 2007, we will more than likely switch at some point and the last 2005 drop will be available from the community site forever (well, for a REALLY long time).

 For my current customer, I’m seriously considering moving to beta 1 of VS2007 as soon as it is available,
 so I prefer to get 2007 support as soon as possible. 

 VS 2005 - although we will eventually be going to the new release - it will probably not be until the
    first quarter of next year.

 Ship for 2005, otherwise we will have to wait at least another 6-9 months to be able to use Service Factory
 for production applications. Most large companies in the Netherlands are just about starting to move from 2.0
 environments and tooling to 3.0. From a developer’s perspective… 2007, since I see no reason to not start using
 Orcas straight away once it hits the street. Service Factory as an enabler to be more productive on the .NET
 platform helps us selling 2007/3.5 to our customers. Given the same level of superb backwards compatibility and
 support we’ve had with the previous versions of the .NET Framework.

And other feedback we've received on this drop:

 1. What about business entity designers? Any plans for the future?

 [from donsmith] We don’t have any explicit plans for a business entity designer. How much different would it
 look than the class designer?

 A genuine business entity designer should allow me to specify a Fowler-style domain model, including stuff like:
  - What properties are to be persisted or not (e.g. derived properties) 
  - Add property constraints and/or business rule placeholders based on the Validation AppBlock in EntLib 3.0
  - Specify the collection classes to be used for associations (e.g. ISet<T> if I use NHibernate)
 This is basically what the Ordina designer could do for me, but, for obvious reasons, I cannot use anymore ;-)

 2. Bug: Add whitespace behind a data contract member and the corresponding generated code will not compile.

 3. Use C# aliases instead of e.g. System.Int32 for the generated code (to comply with the C# coding guidelines).

 4. To keep the solution neat and organized, allow specifying a destination folder within a project. I generally
 try to separate service contracts, data contracts and the implementation from each other.

 [from donsmith] This is not the ultimate solution for mapping to project folders. Wait until you see what we
 have planned. :) And yes, what you’re asking for will be included in the final solution.

 5. Is the structure of the solution as used in V2 going to change radically, or is this new model project to
 become a new member of the generated solution? I’m considering using this new stuff in my current solutions,
 but I don’t want to run into the risk of having to reorganize everything later on.

 [from donsmith] The default solution structure will be the same, but it will be easier to change and save if
 you want to modify it. You shouldn’t have to reorganize everything.

Last edited Apr 16, 2007 at 8:30 AM by donsmith, version 2


Dierk May 7, 2007 at 6:24 PM 
VS2005 support <-> VS2007 support: I'd rather see VS2007 supported than VS2005.