The latest Patterns & Practices Summit hit the conference center on the Microsoft campus. Each day had its own theme -- architecture, agile, development, software factories and applications. The report that follows focuses on the summit's software factory day.
A software factory, for what it's worth, is a configuration of Visual Studio Team System that includes Domain Specific Languages, patterns, frameworks and guidance that all assist in building specific kinds of applications.
The ASP.NET Model View Controller (MVC) Framework
Scott Hanselman kicked things off with a demo of the ASP.NET MVC Framework. This made its public debut during an ALT.NET conference presentation by Scott Guthrie, who indicated in the above blog entry that support for developing Web applications using the model-view-controller architecture has been suggested many times.
The MVC progresses thusly:
- The browser makes a request.
- A route is determined.
- The controller is activated.
- A method on the controller is invoked.
- The controller processes the method, in the process rendering a view and passing in custom ViewData.
- Finally, URLS are rendered, pointing to other controls.
Hanselman described the MVC Framework as an alternative to, and not a replacement for, Web Forms. What the MVC offers, he said, is cleanliness -- clean separation of concerns (thanks to test-driven development), clean URLs that are friendly to SEO and to REST, and clean integration with ASP.NET. It also, as he put it, plays well with others -- one cau use NHibernate for models, Brail for views and Python or Ruby for controllers.
According to Guthrie, a public preview of the ASP.NET MVC Framework will be released by the end of year. "We'll then ship it as a fully supported ASP.NET feature in the first half of next year," he wrote here on his blog.
Or, as Hanselman put it: "Microsoft has been talking about it ad nauseum and we will give them to you someday."
Domain-Specific Development with Visual Studio DSL Tools
Gareth Jones began by breaking down the term domain-specific language into its component words.
Domains can be both horizontal, across application tiers, and vertical, across types of applications. Languages can be textual, forms-based, graphical or mixed; "It's important to think about it as a pretty wide range," Jones noted. Modeling measures the variability between systems, such as generated and interpreted code.
Then he moved into Visual Studio's DSL architecture. Here a domain model framework and a design surface framework are bound to Visual Studio through a shell framework. Meanwhile, a validation framework and templating engines sit alongside the domain model framework. From here, one can generate models and a standard .NET API that includes shell code, shapes, class mapping, a directive processor and so on, Jones said.
Patterns of Software Factories
Wojtek Kozaczynski -- the self-proclaimed "man with the unpronounceable name" -- told the audience about his analysis of the "pattern clusters" that exist within the Patterns and Practices group's Software Factories.
One trend Kozaczynski noticed was layering, or the separation of an application's various tiers. The client software factories -- there are separate ones for mobile, Web and smart client applications -- "are not that picky," whereas the Web Service Software Factory makes layering explicit.
As a side effect of this strict layering, the WSSF also has a strict data mapping system -- the information model for what goes over the wire, the business entity model and the data model for mapping the database to the business logic.
All the factories, though, allow for composite applications, which are composed at runtime and are assembled from modules that have been developed independently. Applications host root containers, which host containers, which host those modules.
(Additional pattern clusters were discussed, but your correspondent had to duck out of Kozaczynski's session for a meeting and missed them. Links to the speaker's recommended resources will appear here momentarily.)
Web Service Software Factory Modeling Edition
The release of the Web Service Software Factory Modeling Edition preceded the session about it by an hour or two.
Presenters Bob Brumfield and Ade Miller noted that this new factory has two target audiences. One is Web service builders who will simply take the factory and use it. The other is factory and framework builders who will embed the factory in their own work.
As for the factory itself, it contains two sets of components. One is core components like the DSL, a project mapping manager, and validation, the theory behind which is that architects can use DSL without cracking the code and having to recompile the factory. The other set is pluggable factory components like validators and extenders.
As for code, the factory generates WSDL using text templating in a process very similar to ASP.
Web Client Guidance with the Web Client Software Factory
Puleio offered a demonstration of some new features that were added after the v1.0 release of the factory. One is the Ajax-like contextual AutoComplete, or the suggestion pattern, which uses JSON to get form fields play off one another, so that, when, say, an end user selects a state, the list of cities in the form below it is limited to the cities in that state. Another is validation, which uses behind-the-scenes postbacks for on-the-fly validation across different tiers of an application.
Then Puleio discussed how the MVC, and the MVP, fits into the Web Client Software Factory. In the Model View Controller, input goes into the controller, which sets the view; code runs before the view is selected. On the other hand, in the Model View Presenter, as in Web Forms, input goes into the view, and the presenter goes to the model; the system, then, chooses the view.
MVC is decoupled, it is more maintainable and extensible, it has fewer moving parts, and it is part of Microsoft's platform, Puleio said -- but most of the controls architects are used to using won't work, he added. On the other hand, MVP fits well with Web Forms and WinForms, thus enabling testability, but it involves extra classes and code and therefore has a steeper learning curve, Puleio noted.
Using Team Factories
Up next were David Trowbridge and Mark Groves to walk the audience through team factories, which the Patterns & Practices group is working on as a means of extending the guidance within software factories to all roles of the software development life cycle.
Through this factory, a project manager can choose tasks from an auto-generated list, suggest a length of time for completing that task and attach to that task some relevant how-to information. That information, in turn, points users to the appropriate patterns and practices for unit testing, performance testing and the like.
These Team Factories will be compatible with Rosario, the version of Visual Studio Team System that will follow VS 2008 and a CTP of which will be available as a Virtual PC soon, Trowbridge said.
Building Your Own Software Factory
Software Factory Day ended with a quartet of presenters -- Brumfield, Kozaczynski, Miller and Jezz Santos -- talking about what went into building the Web Services Software Factory, which consists of, among other things, 11 recipes, 26 model extensions, 18 domain templates, 62 validators, and 20 Visual Studio templates.
Based on the experience that went into building this factory -- a team of 15 working over eight months (with, admittedly, not everyone working full-time on it) -- Kozaczynski offered the following five recommendations:
- Bring a Visual Studio extensibility expert onto your team; that is, someone who knows about DSLs, the Guidance Automation Extensions and Guidance Automation Toolkit, and the Visual Studio SDK.
- Have installation of setup expert available to the team -- and do this early.
- Work with domain experts up front to minimize model changes, and be sure to get detailed user experience stories.
- Provide drops to your user community early and often.
- Reuse as much of WSSF as you can -- that is, don't re-invent the wheel.
Santos also offered some nuggets of knowledge for architects to consider before beginning a software factory project.
- Solutions that are going to be modeled in the factory should be built before the factory itself is built.
- Keep in mind that the factory-building process will take two to three times longer than a one-off product such as building a Web service from scratch.
- Finally, keep in mind that ROI will not come until the factory has been put to use at least three times.