Поделиться через

The EFx Software Factory

  • Статья

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:

Automated Guidance

  • Avoiding the 'Visual Studio Stare'.
  • Provide an obvious means of starting with solution development design process without a requirement for up front detailed design documentation.
  • Knowledge transfer from the guidance to the developer throughout.
    • Allow the knowledge that went into the creation of the guidance emanate through as learnings to those using it.
  • Make solution development a creative, visual, repeatable, predictable and enjoyable task.
    • Provide guidance that models human solution development, so that it 'feels right' and follows a predictable and familiar path - discoverable.
  • Allow solution development to evolve as the requirements for the solution evolve - agility.
  • Capture the design in artefacts that remain relevant throughout the solution life-cycle.
    • Focus upon capturing the intent, the assumptions, decisions 'the unquantifiable experience' of the implementer.

Abstraction

  • Allow the developer to maintain a holistic 'point of view' of the solution, so they don't become deeply focused and entrapped by specific technology implementation and its intricacies and constraints.
    • It is solution development after all!
  • Provide design artefacts that capture the intention of the design, at a sufficiently high enough detail to avoid technology constraints.
  • Let the tool do the hard work, automate where possible, create where not.

Extensibility

  • Leverage and extend existing familiar domain specific languages where possible and appropriate
  • Don't create yet another unfamiliar experience.
  • Integrate with other specialised guidance toolkits that focus on a specific pattern or technology, and leverage that guidance
  • Don't attempt to specialise in all areas, or encapsulate all aspects of solution development.

Customisation

  • All guidance artefacts should offer a level of extensibility and customisation to suit a variety of styles, processes and organisations.

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:

  • The Guidance Automation Toolkit (GAT). GAT is built upon Guidance Automation eXtensions (GAX) which provides a foundation for defining recipes and executing custom actions within the Visual Studio IDE.
  • The Domain Specific Language Toolkit (DSL). The DSL toolkit enables the creation of domain specific languages to model software concepts, easily.
  • Visual Studio Application & System Designers. These designers enable architects to define systems based upon the high level components of a system and allows the definition of deployment settings and constraints that can be validated at deployment time. The designers provide a visual representation of the components and the relationship between them, and provide several different viewpoints of the system and how it is deployed.
  • The Managed Package Framework. This framework allows custom packages to be built and provide Visual Studio integration elements such as custom commands, menus, editors and tool windows.

Generation Time

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.