Last week I presented this topic in Zurich, based on p&p ObjectBuilder.
It's amazing how much interest people show around this topic, yet there
is so little available on the web about ObjectBuilder.
The
project has been open sourced for a while now, but the lack of good
documentation and a full DI container hindered its adoption. First
thing I hear on these conferences is that it's too low-level, and that
higher level APIs are needed.
I believe that's what will happen in the short-term. ObjectBuilder is a
very good tool to apply simple dependency injection and object
composition functionality in your app, without taking huge
dependencies. For the most part, you can make it work even without
using custom attributes and the like.
You can get the slides (PowerPoint 2007), and download the sample project that compares the usage against standard hardcoded dependencies and even Pico and Spring.
I've just now noticed that Ron Jacobs has uploaded our talk in TechEd Barcelona back last November.
It was supposed to be about designing orientation aware and DPI aware mobile applications using the Mobile Client Software Factory and its Orientation Aware Control Block (see http://orientationaware.net/ ;)), but ended up being about other parts of the factory, about ObjectBuilder and optimizations I did to avoid runtime reflection to inject dependencies, CAB, mobile development in general, etc. It was a fun interview :).
Go ahead and download it!
Software factories is an elusive concept nowadays. In this article, I will try to help you understand which technologies can be used today to build production-quality factories and the reasons for the perceived inconsistency in the tools and the vision on Microsoft's part.
None of what follows is speculation: I've been a main developer on one of the two core technologies that realize today' software factories (patterns & practices Guidance Automation Toolkit or GAT), and as such I've been in close contact with the teams and architects building the technologies I will explain here (including Jack Greenfield, Wojtek Kozaczynski, Mauro Regio and others). Also, my company is a leader in software factory development, providing most of the people that build the factories coming out of the most active practitioner in the area today: the Microsoft patterns & practices group. We also have several customers around the world that we helped reap the amazing productivity boost that today's factory tools can bring.
First and foremost: this article is NOT about the grand vision (still underway, rest assured, but nevertheless in the realm of the future) outlined in The Book: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, Keith Short et all. I will talk about technologies that are ready for production today. This also means that the strict concept itself of a SF outlined in the book needs to relaxed for what's currently possible with the available tools. You can think of today's factories as infants that will grow with features as times goes by and the end-to-end SF vision becomes a reality. That doesn't prevent the "infant" from giving you a big boost in terms of productivity and software quality.
You can build SF today by using a combination of the following two tools:
-
DSL Tools: or Domain Specific Language Tools. This is a toolkit for creating VS-integrated graphical notations for a given model that you basically make up. It allows you to construct a custom-tailored designer for a model for your problem domain.
-
GAT/GAX: or Guidance Automation Toolkit/Extensions. This is a toolkit for extending VS with solution, project and item templates, code snippets and so-called recipes (or developer use cases) exposed as context menus within VS, that guide the developer in completing a complex task.
The problem is that integrating the two is not a trivial task. Why you may ask? Aren't they both coming from Microsoft? And how does GAT/GAX fit in the SF vision? After all it's not even mentioned in The Book!
Glad you asked ;). In order to understand this "mess", and figure out how to make it work for you, you need to understand a little bit of the background behind the two technologies. The DSL Tools is basically the first step in the road to realizing the full SF vision outlined in The Book. Hence, if you try to build a real-world factory just using DSLs, you will find it fairly incomplete and not supporting typical scenarios such as providing an initial solution structure where you will put your DSLs, etc. The missing features, though, are most probably those that will come (or become unnecessary) as the full vision is implemented. In the meantime, it feels lacking.
On the other hand, Microsoft patterns & practices (p&p) is NOT about building a compelling but somewhat distant feature, but about solving customers' problems today. p&p follows a process called "Customer Connected Engineering", which means customers get to influence what we do. Delivering guidance on how to best use the platform has been p&p traditional focus, but as guidance became more and more complex, thicker books and more complex libraries (think CAB and EntLib) just didn't cut it anymore. Customers were not getting the guidance in an easy to consume way. Hence, we set out to find a way to bring the guidance into Visual Studio, in a way that was easy to author (not only for p&p but for other companies delivering guidance internally) and contextual. The readily available VS extensibility mechanisms (add-ins and VSIP packages) did not satisfy either requirement, so we built our own framework on top of VSIP to allow for easier extensibility. And GAX was born. As the name implies, it's a mechanism for automating the guidance that you would have to otherwise perform manually by following a book's instructions.
You may notice that p&p software factories do not contain DSLs. This is in part because the goals of p&p SF are somewhat different than The Book SF. Their main purpose is to guide the developer through the best practices for implementing a given solution. In the end, it's the developer himself who implements the solution. It just so happens that he does so much faster and in a predictable way because he uses automated guidance within VS that generates code, unfolds boilerplate projects and solutions, provides code snippets, etc.
Given the different origins and goals of the two technologies, it may seem that they are hopelessly irreconcilable. Fortunately, that's not necessarily the case, and there are many ways in which they can be integrated. My partner Victor Garcia Aprea and Mauro Regio have published an article on MSDN about integration scenarios that include integrating the two.
A number of integration points are particularly critical:
- An initial solution structure is generally required: this can be done with GAX.
- Typically at a specific location in the solution, a domain model/designer could be added to design some area of the application (i.e. a business entities domain model, that generates business entities + data transfer objects + data access layer code + SQL files with stored procs for the DB). This needs to be done with a combination of DSL and GAX if you want the DSL to only be available at a specific location in the solution. (remember, GAX is about context)
- With the DSL in place, you may want to generate multiple code files (as in the case of the business entities model I mentioned above), maybe even in different projects, and maybe you even need to generate the projects themselves. Again, DSL tools alone is not enough. By default, it will do two things that are pretty bad for a real-world factory:
- The code (a T4 template) that transforms the domain model in a designer into actual code for your project is expected to live in the same project as the domain model file. You are given a custom tool that runs the transformation, and a solution explorer toolbar icon to run all the transformations in the solution/project ("Transform All Templates"). What kind of guidance are you giving your developers if they can modify it at will just by modifying the T4 template that generates their code? It's more like giving them an example that they can tweak, and typically you don't want your developers modifying the templates for code generation that your architects together with your senior devs have created to ensure quality code.
- Each T4 template results in exactly one big file with the output of running the codegen against the domain model. If your model designs business entities, you will end up with a huge file with all the entities in the model. Generally not a good idea, and certainly goes against the typical .NET coding practice of using one file per class.
And it will not do the other two things that you need: generate new projects, and generate files that target multiple projects. You can supplement the DSL with GAX in order to achieve all of this. Achieving the above two goals requires deep understanding of how both technologies work at a very granular level, though, but it's definitely possible (more on this later).
- You may want to launch recipes/execute actions from specific shapes in the domain model diagram (i.e. "Configure Security for Entity" or something like that, maybe even regenerate code for a specific model entity and not all of them). You can hook GAX recipes to the context menus on DSL diagrams pretty easily, and with some more work you can make it contextual enough to provide very granular visibility (i.e. only model entities that have property Foo = true).
Of course, the integration is not as seamless as it could have been. But I hope I shed some light on the current situation by sharing the background and how the two tools came to be. Moving forward, you can expect the experience to become much better, as the scenarios that led to GAT/GAX are integrated into the SF toolkit.
As you might have guessed, we (Clarius) have gone over each and every hop in this integration that you can possibly imagine. We have recently released a CTP of our Software Factories Toolkit, which helps integrate the two technologies, and which you can download for free.
I will be presenting some of the work I did for the patterns & practices Mobile Client Software Factory. It's been very fun to work on that project, and I plan to share as many tips & tricks on how the amazing Orientation Aware Control does it magic as attendeeds dare to ask ;-). After doing extensive research, I think this control is the only one (and with free source) that showcases some really advanced custom control development in general and in particular for the mobile platform. Session details:
DEV342 Designing Zero-Code Adaptive User Interfaces (UIs) for Windows Mobile
Daniel Cazzulino
- Fri Nov 10 10:45 - 12:00 Room 121
Designing mobile applications that support multiple form factors and resolutions is probably one of the most time-consuming and challenging aspects of mobile development. It is also the one that differs the most from traditional desktop application development, where simple docking or anchoring is usually enough. The Microsoft patterns & practices Mobile Client Software Factory comes to the rescue in this area, with the Orientation Aware Control, which allows designing and coding a single control with multiple layouts or skins, that are automatically applied at run-time (and design-time) according to the available form factor, resolution and orientation. You will learn not only how to apply it successfully to your projects, but also how it was implemented, directly from its core developer. With its outstanding Visual Studio forms and user control designer integration and zero-code adaptive UI behavior, the Orientation Aware Control is a must-have companion for any mobile developer. Being distributed in source form, it also makes for an excellent real-world example of advanced (mobile) custom control development techniques.
This will be a sample / source code driven session, with just a few slides to set the context.
As part of the
Mobile Client Software Factory I've been working on for the past few months,
we introduced the Orientation Aware Control (OAC). I blogged about it and showed it working. In this post I'll delve a little more on the process you go when building UIs for devices that must adapt to different resolutions and orientations.
I've already
hinted that the solution we implemented is based on the
Localization feature in .NET. So let's see how you go about using it.
First step is to add a new UserControl to your project, and changing the base class to inherit from the OrientationAwareControl class provided with the factory. After you do that, you will see something like the following:
New and modified properties:
- Localizable: as you can see from the property description from the above screenshot, this property is fixed to the True value. This is the proof that OAC uses the localization feature, and therefore this property cannot be changed.
- Orientation: this property can have the values Vertical | Horizontal, and corresponds to the Rotate command (both in context menu as command area in the properties window). It basically allows you to design different UI for the portrait and landscape orientations.
- Resolution: this property allows you to select one of the available resolutions. These resolutions can be the standard ones (VGA and QVGA standard or square), and will show up in a dropdown. More on how this list is populated and how to add custom resolutions later.
New commands: the commands, as is usual on custom control designers, are available either from the context menu of the control and in the command area in the properties window.
- Rotate: rotates the current layout, so that you can start designing the rotated layout. By default, the first time the control is rotated, controls bounds will be checked to see if they fit in the rotated control (height and width are switched). If they don't, they will be moved up and left until all controls fall within bounds of the container user control.
- Switch to Default Layout: by design, in VS2005 you can only add new components/controls through the designer if the current control/form is in the default culture. Because the OAC extends the localization infrastructure, the equivalent of the default culture is the default layout, meaning default culture + default resolution and vertical orientation. More on how to set which is the default resolution later on.
- The other three commands help in designing localized versions of the different resolutions. Basically, whenever you start with a new locale (say Spanish), the default layout is applied to the new resolution/orientation/culture, which is probably not optimum depending on which locale you are designing. For example, say you have QVGA-Spanish already designed, and now you want to design VGA-Spanish. The default culture layout will be applied and auto-scaled to give you a starting point. Well, in the localization case, you probably want to have all the labels and other text properties applied too, so that you don't have to translate everything again. Copy Text Properties is there for that purpose. You just switch back to the QVG-Spanish layout, click Copy Text Properties, and back in the VGA-Spanish, you click Paste Properties. All text properties will be set in all controls, saving you quite a bit of time. The same goes for the layout properties. If you already designed the layout for one, say, VGA-Horizontal resolution, and now you're localizing it, in every locale instead of re-locating all controls, you can simply Paste Properties after you run the Copy Layout Properties from the "source" layout (i.e. VGA-Horizontal, Default culture). Layout properties are basically location and size.
As you see, there's NO code whatesoever that you need to write to detect the current screen size and apply the appropriate resource. All is done automatically by the base Orientation Aware Control. In addition, and because we're reusing the localization feature in .NET, layouts are "inherited" across locales. Also, when no specific layout is found for the current resolution (i.e. a new device just came out), the default layout will automatically be applied.
How do resolutions work
I said above that the available resolutions are rendered as a dropdown you can pick from in the properties window. Here's how it looks:
Notice the description at the bottom of the window. This description is dynamic, and reflects the form factors that support the given resolution. So where is this information pulled from?
This is a pretty advanced control, which was very fun to develop. Turns out that there's an IPlatformInforma