Its been a while since I talked about progress on EFx and its factory.
We have got to a point now where we can start to demonstrate the factory and how it operates. We still have some way to go to complete the implementation of the finer details, but a picture speaks a thousand words, so I am now in a position to show you some of what it looks like currently.
(I am gonna do this in several articles, so we are just gonna start with the big picture stuff first)
Factory Background (Thanks to Edward for reminding to put his section in here - duh!)
If you have been following the articles on EFx earlier on here you'll know that EFx is an Application Framework for building enterprise distributed applications and services. In actual fact, like most frameworks, EFx helps builds 'baseline' implementations. That means it provides all the frame-working code and the common stuff developers need to build a real implementation. EFx has been successful in helping provide the architectural structure and class libraries to enable rapid and predictable development of these types of applications and services. One of the advantages of this framework is that it leverages Enterprise Library under-the-covers to provide access to common service providers and application blocks. EFx also provides a number of extensions to Ent.Lib to 'round out' the functionality it provides.
So, one of the major issues with EFx (as with any other framework) from the practitioners point of view, is that they had to learn quite a few new concepts about using a framework, and actually crafting the architectural solution structure (solutions, projects, source files etc) was pretty tedious and of course error prone. Not to mention if you changed the name of anything, you had to update a number of source code artefacts all around the place. These issues are not specific to this framework at all, but in fact any Enterprise solution development, with or without a framework in place. The other issue, which was a side effect of using a framework is that the code that the practitioners have to write starts to become very boiler plate like, and again tedious. (Since many of the coding concerns have been absorbed into the framework and architecture, that's the point after all).
So we decided to create an automation toolkit over the framework that builds these apps and services using design surfaces and meta-data definitions (Modelling), that outputs the source code artefacts (Automation) to free the developer from learning all its intricacies (Abstraction) and leverage domain specific knowledge and experience in areas where technology is key to providing a resolution (Extensibility). Our timing was impeccable since at the time of this creation, the Guidance Automation Toolkit (GAT) and the Domain Specific Language (DSL) toolkit were under construction too.
So by combining elements of those toolkits and some other select features of Visual Studio 2005, we have created an 'Architectural Guidance Package' - a 'Solution Development Construction Toolkit' for creating Enterprise Service Oriented Applications and Services all within your favourite development tool - Visual Studio.
Factory Principals and Goals
The guiding principals and goals of the factory are many, most driven from practitioners using EFx before it became automated, and some driven from the new 'Software Factory' initiative emerging within Microsoft. I'll list a few here so you get the basic idea:
Together these guiding principals have driven the development of this factory towards the goal of automating and guiding the solution architect and developers through most of the aspects of creating enterprise applications and services.
It should be mentioned at this point that due to the issues discussed in File | New | 'Blank Problem' that we are not attempting to automate everything - don't fret. We recognise that the one thing we cannot automate today is the business logic of the system, for this we allow the developer to still write code that does this, but for all other aspects which amount to mostly architectural concerns, we describe these at a higher level of abstraction and therefore are able to provide an guided automated solution.
Design Time Experience
The factory provides a design time experience that is intended to be familiar to the user, by utilising the design tools available in Visual Studio today.It 'configures' Visual Studio to provide a customised environment that enables the development of solutions specific to the domain of constructing end-to-end enterprise applications and services. The toolkit does this by leveraging several technologies that are integrated into Visual Studio including the following:
Since one of the objectives of the factory is to reduce the maintenance/improve the quality of the code it generates, and provide reusable components, the factory generates source artefacts (applications & services) that are built upon the application framework foundation (EFx).
These source artefacts are created by the factory from modelling the domain of enterprise application and service construction, using specific designers and specialised tools, that generate the solution and source for the layers and components in that solution.