This is a brilliant tool. I really like the way the Service Hosts can dynamically retrieve configuration info using OData. This will definitely simplify configuration management. Looking forward to the other episodes.
Spring is an IoC container while MEF is for plugins. An IoC is used when you know your dependencies at design time and typically deals with "one" dependency (for that area of the app) while MEF deals with many.
For example, with IoC, at design/debug time you may inject a simple console logger for your app or even a mock logger while at production/runtime you will replace it with a proper logger that writes to a file or database but with MEF at runtime you are looking
to discover "all loggers" that are available and call them (of course you can just pick up a single logger using the catalog) so your output can be piped to many.
You could use MEF to wire dependencies like an IoC but it is not meant for or optimized for such behavior. MEF also has advantages with the way stuff is exported and imported in that it is not tied to types which means that your app can be opened up to plugins
written in dynamically typed languages.
The plans for the mapping wizard sound interesting. Just one thing to be careful of, IMO you would need to store what the user entered the first time somewhere because if things change, especially in complex mappings, the user wouldnt want to go through all
the steps again from the beginning. The Service Factory Modeling Edition with its targeted /selective updates was definitely superior to the ASMX edition where we had to re-step through the wizard from the beginning.
Very interesting video. Infosys has done a nice job in demonstrating the use of Blueprints and the amount of stuff generated without resorting to manual plumbing code is very nice.
The one issue I had with the implementation of the solution was the generation of WCF wrappers directly from the DAL classes. Farukh mentions that mapping classes will also be generated to map the service entities to data entities and vice versa, but this seems
rather pointless when you have already generated the service entitites from the data (unless you are just putting in a placeholder to handle maps if the service entities change in future. But in general, this pattern is only good for 'data interfaces' (ie)
vanilla wrappers over the data entities. For more 'business' oriented services, the messages tend to have a flatter schema rather than the deep inheritance trees that a domain model might generally use. The contracts in turn could be very different from the
business entities so a full fledged translation is important.
I think a better approach would have been to have a separate model for the service contracts and data contracts like the
P&P Service Factory and then show how a mapping cartridge could be built to map the two.
Speaking of models, I would like to know how this implementation handles changes in the contracts. Do you regenerate the entire code base (like the first ASMX version of the Service Factory) or can you update only portions? Would be cool to see another video
on this Infosys factory to see how updates and changes to entities/contracts are handled.
Debates on patterns aside, this is still good work.
Reply to Minh,
Reading the summary post will NOT tell you all about Blueprints. Check out the link to the MSDN homepage for Blueprints and the articles there namely "Introduction to Blueprints" and "Inside Blueprints". Also, as those articles point out Blueprints are in some
ways an evolution of GAT/GAX so a general understanding of guidance automation will help, in my opinion (although not essential).
The core idea is to be able to take guidance that was formerly passive (like the various books P&P and others published on Web Services patterns and other development best practices) and make it into something more executable within Visual Studio so an architect
or team lead can bake into VS the steps that the team should generally follow for a consistent output.
Very interesting. Rico's illustration of the single threaded approach as analogous to the relay race is very good indeed. By the way, I just saw Tim Wagners PDC session on "Extending and Customizing VS"
as well. It's good to see that the editor is going to be fully managed. I agree that not everything needs to move to managed code. Just the parts that devs have to interact with can be simplified.
I'd be interested to see if MPF becomes any simpler to use , or rather, if it takes less code to do things. Couple of things I have come across and have a question on whether VS10/11/x will address
Istvan Novak's VSXTra library is a layer on top of MPF that I think is sorely needed. Will that be one of the things addressed in VS10 ( a simpler MPF) ? (2) Have you seen Victor Garcia (of Clarius Consulting) post on "Simple things which are incredibly hard" where he points out a couple of areas where things that should be
simple one or two lines of code end up being very long winded. I guess VSXTra will help now but again, are we taking this on board for VS10(+) ?