Now, the annoying thing is – what if one of those components needs to be scoped per-HTTP-request?

In Autofac 2.1, you could exclude it explicitly and then perform configuration separately:

I wouldn’t say the repetition here is too bad, but over a larger assembly the separation between the Except() clause and the subsequent registration makes the code harder to follow and thus maintain.

Autofac’s scanning feature is new in version 2, and is slowly evolving towards a minimal syntax. In the latest release, version 2.2, the configuration of an excepted component can be done in-place:

The configuration for the excepted component doesn’t inherit any of the configuration from the outer scanning operation, hence it is necessary to specify the services it will provide despite the AsImplementedInterfaces() clause in the scanning statement. While I think it would be more concise to specify only the differences between the explicitly-configured component and the rest of the scanning operation, override rules tend to bring a lot of subtle complexities with them and so they’re avoided here.

What’s new?

Version 2.2 is highly backwards-compatible with 2.1. Along with many small improvements, the significant additions in the new version are the return of a mutable container model, support for ASP.NET MVC 2.0 and lightweight adapters.

ContainerBuilder.Update() and full container mutability

One of the most controversial changes to Autofac in the 2.1 release was the deliberate omission of an easy way to add more components to an already-built container. The reasons for and against this are worth a blog post on their own, but in the end it turns out that integration into third-party frameworks is especially tough without this feature.

To add components to an existing container, use ContainerBuilder.Update():

Configuration this way is often much harder to follow than a simple ‘register then build’ style, so again, use this feature only where necessary.

ASP.NET MVC 2.0 support

The new release is built against the ASP.NET MVC 2 binaries; you’ll have to compile from source if you want to target ASP.NET MVC 1. There can’t be many projects out there that can upgrade to Autofac 2.2, but not to the new release of ASP.NET MVC, so we expect this will be convenient for most users.

Out of the box, Autofac now supports ASP.NET MVC Areas, and integration with other ASP.NET MVC features is getting richer.

The AutofacControllerFactory policies have changed in this release, so if you previously added controllers by hand (as named services) you will need to update your code to register controllers by their concrete type (without an As() or Named() configuration clause..)

Lightweight adapters

Lightweight adapters are an easy way of expressing “for every registered X, provide an adapter of type Y.”

The introductory article is the best place to find out how this feature works.

Other changes

• COM interfaces using No-PIA (or ‘ embedded interop types‘) can now be exposed as services
• Simplified WCF configuration for self-hosted services
• Scoped registration improvements: SingleInstance() now behaves as expected and binds the instance’s lifetime to the nested scope
• Generic registration constraint checking improvements – more complex type constraints can now be handled when determining the suitability of an open generic type to satisfy a closed generic service
• Additional Resolve()/TryResolve() convenience overloads have been added to fill some gaps
• The same type can now be registered multiple times in a single XML configuration block
• Several usability enhancements have been made to the scanning feature

Credits

This release, as with every Autofac release, is the product of the lively (and growing) community. There have been some especially fine patches and contributions this time around – thank you everyone for your hard work!

Perhaps this is why it is sometimes difficult to reason about how component instances will come together at runtime?

The problem dealt with in this article fits this description – a simple object graph that is unintuitive to build with a typical container.

Back to the Gang of Four…

The classic “Gang of Four”-style Adapter pattern ‘adapts the interface of one class to another’.
Common scenarios where adapter-like structures appear are, for example:

• where a wrapper is needed in order to work efficiently with an underlying abstraction;
• between different representations of the same thing, e.g. the endless variations on ILog; or,
• between corresponding elements in different logical models

We’ll use a fairly broad definition of the pattern, in the context of an image editing application.

A ToolbarButton has an ICommand that is invoked when the button is clicked. ToolbarButton is an adapter for ICommand that allows the command to be invoked from the user interface.

Here we’ve attached an instance of ToolbarButton to an instance of SaveCommand, which implements ICommand. The classes are:

So… from an IoC perspective, what is interesting about this example?

Adapting Multiple Implementations

An application has more than one kind of command. An image editor may have Save, Open and a whole host of other commands:

But, even though all of the command implementations are the different, the widget representing them on the user interface is implemented by the same component.

To bring the example together let’s add an EditorWindow that accepts all of the toolbar buttons as an enumerable dependency.

Our intention here is that for each ICommand in the container, a ToolbarButton will be created to wrap it, and all of these will be passed along to the EditorWindow via the IEnumerable<T> relationship type .

These might be registered with Autofac in the following way:

Yet, there is something wrong. The static structure of our code is correct, but as I lamented earlier, the object graph isn’t what we expect.

The problem is that, as far as the container is concerned, there is only one ToolbarButton component. This will be initialised with whatever happens to be the default implementation of ICommand. Autofac’s last-in-wins policy means that OpenCommand will be used as the default implementation of ICommand, and SaveCommand will be ignored.

This happens because the container builds object graphs top-down; first it looks for ToolbarButton, then it looks for an ICommand to satisfy its dependencies.

Registering Adapters

What we’d really like is to create multiple ToolbarButtons, each attached to a different underlying ICommand implementation.

To configure this, Autofac 2.2 essentially lets us switch the composition of ToolbarButton from top-down to bottom-up. First we find all of the ICommand implementations, and then we construct a ToolbarButton for each.

Configuration of the container is the same as before, except we change:

to:

The RegisterAdapter() method takes two types as parameters: the service to adapt from, and the component type to adapt to.

Autowiring isn’t supported for the adapter component in this scenario (yet), so we include a lambda expression describing how the adapter is constructed given one of the adapted instances.

Overloads of RegisterAdapter() exist for passing in parameters and an IComponentContext from which the adapter’s other dependencies can be resolved if necessary.

Aside: @joshuamck suggested an alternative syntax that I’d also considered, along the lines of builder.RegisterType<ToolbarButton>().Adapting<ICommand>(). I think this is more in line with the intent of Autofac’s builder syntax, so depending on how the implementation goes we might see this in the 2.2 release version.

Composing with Metadata

In the example, commands can be given metadata to allow the command name to be displayed on the button.

First the commands are given names:

Then, the name parameter is added to the ToolbarButton constructor and the metadata is consumed:

Adapters, like other relationship types in Autofac, compose nicely with each other as the use of Meta<T> shows.

Wrapping Up*

*Excuse this terrible pun.

Lightweight adapters are a nice little helper coming in Autofac 2.2. While these scenarios don’t arise every day, when they do, container support is very convenient.

Download an example (including an Autofac 2.2 preview build) here.

If you’re interested in some of the ideas behind the new Autofac 2.1 release, be sure to check out the podcast!

Autofac 2.1 is still the IoC container you know and love, but reorganised so that Autofac 1.4′s strengths — especially in providing a low-friction developer experience — really shine.

You can download the binaries here, or read on for some of the feature highlights.

Component Discovery

Otherwise known as convention-driven registration or scanning, Autofac 2 can register a set of types from an assembly according to user-specified rules:

The registration syntax for RegisterAssemblyTypes() is a superset of the registration syntax for single types, so methods like As<T>() all work with assemblies as well, and there’s very little extra API to learn.

Relationship Types

When working with IoC you frequently hear advice against passing the container around or resolving components from it directly. Where dynamic relationships are concerned, for example deferred creation, selection from alternatives or parameterisation, there has historically been very little guidance on the alternatives.

Autofac addresses this by automatically supporting small, focused, strongly-typed wrappers that express dynamic dependencies.

For example, instead of calling IContainer.Resolve<IDownloader>(), a WebCrawler component that needs to create instances of a downloader on-the-fly can take a dependency on Func<IDownloader> and the container will provide it automatically so long as IDownloader is registered.

As the example shows, you can pass parameters (in this case a Uri) that will be forwarded to the target component’s constructor.

Autofac 2 supports an extensive vocabulary of relationship types that the container understands and provides automatically based on the other available components.

For more information on relationship types, see the introductory article.

Component Metadata

If you’re familiar with the Managed Extensibility Framework (MEF) you have probably seen examples using component metadata.

Autofac uses the underlying support in .NET 4.0 to provide similar functionality. Metadata is associated with a component either in code:

Or in XML:

Unlike a regular property, a metadata item can be queried and used without requiring an instance of the component to be created.

This makes it useful when selecting one of many components based on runtime criteria; or, where the metadata isn’t intrinsic to the component implementation. Metadata could represent the time that an ITask should run, or the button caption for an ICommand.

Other components can consume metadata using the System.Lazy<T,TMetadata> type.

In .NET 3.5 (as well as 4.0) Autofac 2 provides the weakly typed Meta<T> class for consuming metadata as a dictionary.

Managed Extensibilty Framework Integration

MEF introduces a standard API for creating extensible applications in .NET 4.0. If your Autofac-based application has extensibility points, plugin developers can use the MEF attributes to mark up their extensions, while internally they can be hosted in the Autofac container just like any other Autofac component.

Any MEF catalog type can be registered directly with the container, so to use MEF’s directory scanning ability for example, a System.ComponentModel.Composition.DirectoryCatalog can be used.

For documentation on this API see the Autofac MEF integration wiki page.

There’s a deeper discussion of the underlying architecture here.

Other Improvements

Although Autofac 2 introduces some new features, a lot more work went into making the core architecture and API of Autofac more consistent, robust and explicit.

To list a very small selection:

• Generic type constraints are now respected – Autofac won’t try to use unsuitable generic types when resolving references to generic services.
• The instance parameters to activation events are strongly-typed, for example builder.RegisterType<Foo>().OnActivating(e => e.Instance.Start()).
• ASP.NET MVC controller registration is more flexible and simpler via the RegisterControllers() method.
• Non-shared (‘factory’) scope is the default, rather than Singleton.
• “Resolve Anything” support
• API documentation is seachable on Google.

Upgrading from Autofac 1.4

If you’re upgrading from an earlier Autofac release, see the New in V2 wiki page for more detailed information.

There are many breaking changes for users of Autofac 1.4 who want to upgrade. Most of these are just name changes, but some less commonly-used features will cause non-trivial rework. This is the price of keeping Autofac clean, supportable and relevant – if you’re affected by breaking changes you can find consolation in knowing that Autofac is not on the path to becoming a legacy framework .

If things do get tough, help is only ever an email away.

Where to Next?

The 2.1 release is largely foundational — its focus is on improving the core container. There are plenty of new features in it, but next in the pipeline is a 2.2 version including, for example, broader ASP.NET MVC support and no doubt some fixes and improvements based on learnings from 2.1.

Acknowledgements and Thanks

Autofac 2 draws on many inspirations and input from a large community. Direct credit for Autofac 2 belongs to the project members, contributors to the mailing list, and supporters in the blogosphere, on stackoverflow and on Twitter.

Many of the ideas in Autofac 2, just as with the version before it, derive from other projects like Windsor, MEF, Funq, Unity, Ninject, StructureMap and their precursors.

Extra thanks is due to the MEF team, whose tireless work is making the .NET a friendlier place for IoC every day.

Quartet Cube

If you’re a fan of index cards or Post-it notes for work item tracking, here’s another simple helper you might enjoy.

The Quartet Cube is a tiny, portable metallic whiteboard.

On our recent project we’ve kept three in the project room and found them perfect for:

• Taking notes during meetings
• Small focused to-do lists (we often use a pink one to track things we’d like to refactor)
• Sketching ideas
• Communicating designs (as demonstrated in the photo by the remarkable Steven Nagy)

The added portability makes it easy to take one to your desk – or to somebody else’s.

Autofac 2.1.9 includes the last of the critical changes for a full release. Since 2.1.8:

• Many bug fixes and small usability enhancements
• BeginLifetimeScope() now allows additional components to be configured for the child scope
• An AutofacContrib build for both .NET 3.5 and 4.0 is available (AutofacContrib.DynamicProxy2 not yet included)
• Two new adapters for the zoo:
  • Indexed<TKey,TValue> for dictionary-like dependencies
  • Meta<T> for un-typed metadata, available on .NET 3.5
• API documentation can be viewed online at api.autofac.org (this reflects the .NET 3.5-compatible version.)

Autofac 2.1 RC is now the recommended version for new projects. Please bear with us while the wiki is updated to reflect the new API.

Many thanks are due to the contributors and user community who have made this release possible, as well as my teammates at Readify who have put up with a bombardment of Autofac 2 material in the last few months

Get the downloads for .NET 3.5 and .NET 4.0 here.

Components rarely exist or perform any useful task alone. A system that achieves a business function may use tens, hundreds or even thousands of different components, all working in collaboration to get a job done.

Early IoC containers understood one kind of relationship: “A needs a B.”

More complex relationships, like “A creates instances of B” required the author of component A to deal directly with the container to get things done, by calling container.Resolve<B>(), for example.

Since a majority of relationships are, in fact, simple direct dependencies, this was an acceptable point from which to start developing IoC containers as a technology. Recently, more powerful, declarative ways of specifying “higher-order” dependencies have emerged. In this article we’ll look at a selection of them, using Autofac 2 as an example implementation.

I was first introduced to the term “higher-order dependencies” by Mircea Trofin at Microsoft. I’m not sure I’m using it here in precisely the same sense. The .NET Composition Primitives, which Mircea was instrumental in creating, have some elegant mechanisms for handling them – in a future article I hope to cover this in more detail.

A Catalog of Relationships

It turns out that there are a lot of different ways that one component may relate to another.

Here’s a partial list to fill in the question mark above:

1. A needs a B
2. A needs a B at some point in the future
3. A needs a B until some point in the future
4. A needs to create instances of B
   • and provides parameters of types X and Y
5. A needs all the kinds of B
6. A needs to know X about B before using it
7. …

This list is chosen carefully, because each of these relationships can be expressed declaratively through simple adapter types.

Some of the types above will be familiar: Lazy<T>, Func<T> and IEnumerable<T> are all .NET BCL types, and are used here with their standard semantics.

Owned<T> and Meta<T> are introduced by Autofac, and fill some of the gaps in the BCL. They’re very simple types that could be replicated in an application that wanted to use them independently.

Lazy<T>

A lazy dependency is not instantiated until its first use. This appears where the dependency is infrequently used, or expensive to construct.

Owned<T>

An owned dependency can be released by the owner when it is no longer required. Owned dependencies usually correspond to some unit of work performed by the dependent component.

In an IoC container, there’s often a subtle difference between releasing and disposing a component: releasing and owned component goes further than disposing the component itself. Any of the dependencies of the component will also be disposed. Releasing a shared component is usually a no-op, as other components will continue to use its services.

Func<T> and Func<X,Y,T>

The ‘factory’ adapters imply creation of individual instances of the dependency. The parameterised versions allow initialisation data to be passed to the implementing component.

IEnumerable<T>

Dependencies of an enumerable type provide multiple implementations of the same service (interface).

Meta<T,M>

Metadata is data-about-data. Requesting metadata with a dependency allows the dependent component to get infomation about the provider of a service without invoking it.

The Relationship Zoo

If you’ve read this far, you’re probably desperate for an example that doesn’t use the components A and B. I feel your pain! The truth is, while these dependencies are useful in their own right, really interesting dependencies often combine multiple adapters!

Choosing a File Viewer

Metadata is excellent when there are multiple implementations of a service, and one must be selected to perform a task. The selection criterion mightn’t be inherent in the component itself, so properties make awkward choices for representing this data.

Let’s say we have a number of file viewers, and, via configuration, we associate each viewer with the file types that it should be used to view.

In this example, IEnumerable<T> and Meta<T> are combined to express the two features of the relationship between Browser and IViewer.

Mixing in dynamic creation, controlled lifetime or lazy initialization would often also make sense in this kind of scenario.

You can see how metadata is associated with an Autofac component here, or examine one of the many examples based on the MEF APIs here.

Creating and Releasing a Message Handler

Another common combination is that of dynamic instantiation and ownership of the instances. A message pump may create, use, then release a handler for each incoming message:

Many instances, with dynamic creation and controlled lifetime and parameters and and and whoah!

Yes, IEnumerable<Meta<Func<X,Y,Owned<T>>,M>> is in fact a valid relationship type. Glad you asked?

Common combinations can be eaiser to work with when they are baked into a single class. In MEF, for example, Meta<Lazy<T>> is represented as Lazy<T,M>. Likewise Func<Owned<T>> is represented as PartCreator<T>. You can plug these composite adapter types into Autofac via a custom registration source if you need them.

Custom delegate types can also ease angle-bracket-eyestrain if you use the parameterised factories a lot.

The core of Autofac 2 doesn’t have any special knowledge of any of these adapter types. They’re all plugged in as IRegistrationSource implementations, meaning that you are free to change or extend the set of adapter types as your needs dictate.

Muahahahahhahahaahhh!!!!

I heard that maniac laugh just then! Let me just slip in the disclaimer now: just because you can model almost any conceivable relationship type this way, doesn’t mean that you should. Where a simple direct dependency will suffice, don’t gouge out your eyes on six layers of nested angle brackets, or invest in new adapter types. Like all sharp tools, use context adapters with discretion.

At the same time, there’s practically no excuse to use IContainer or IComponentContext in your components anymore.

Conclusions and a Suggestion

You might not be using Autofac today, and might not have any desire to. That’s okay! Anything new and useful you see here will no doubt make its way back into the container you prefer – this is the magic of being part of an Open Source community.

If you do use Autofac, or are curious, download the .NET 4.0 version from the project site.

A note to container developers…

Although this is an Autofac-centric article, it draws on the combined experience of many passionate people who are driving .NET composition technology forward.

I’m not sure yet that we share a common vision of the “v.Next” IoC container – one thing we do seem to agree on is that it is harmful to have the container abstraction leak through into components. Perhaps in the future, IoC containers will be completely transparent, but we have some way yet to go.

Common Service Locator (CSL) was a step forward in interoperability. A good range of applications and frameworks that need dynamic or lazy instantiation no longer have to depend on a specific IoC container; I think this is one way we’ve maintained diversity and a healthy ecosystem.

CSL is a stopgap though – a service locator that could handle all of the scenarios above would be a monster of an interface indeed! CSL also breaks the declarative nature of components that use it.

I’d be very interested to hear thoughts on a new project, Common Context Adapters, which would include types like Owned<T> and Meta<T,M> to fill gaps in the BCL while it evolves. It would also provide baseline documentation on how wiring of Func<T> etc. should work.

Common Context Adapters would play a similar role to CSL by isolating applications and frameworks from the specifics of an IoC container, but in a way that is compatible with declarative dependency wiring and inversion of control.

I’m prepared to put effort into making this happen if there is enough interest.

Our current project includes a small workflow for submission and approval of user account creation requests. This makes a good example to discuss domain-specific languages and Sprache, so I’ll paraphrase some of the requirements here.

The set of user account types is open-ended; currently “employee”, “contractor”, “temporary” and so on. To request a particular kind of account, a user must fill in a questionnaire associated with that account type.

In the data collection and approval parts of the system, the content of the questionnaire is irrelevant so long as the necessary information is recorded and presented to the administrator, who will ultimately approve or decline the request.

The Challenge

Much of the system design is driven by the fact that the set of possible account types (and thus different questionnaires) is open. Creating new questionnaires should be possible without redeploying the application. Furthermore, the content of a particular questionnaire needs to be easily extended and modified, possibly by end-users themselves.

There are many possible ways to represent the questionnaires:

• Map a questionnaire domain model to relational database tables
• Create an XML-based questionnaire format
• Use Windows Workflow Foundation with loose XAML files
• Read the questionnaires from CSV files or spreadsheets

Each has its pros and cons with regard to ease of implementation, maintainability, user-friendliness and flexibility.

In this article, we’ll examine another appealing option: building a user-friendly mini-language to represent questionnaires.

Questionnaire Definition Language

You may have read some discussion of the differences between internal and external DSLs.

An internal DSL is a specially-constructed API in a general-purpose language like C# that, when used, reads more like a definition of the problem than a program to solve it.

An external DSL is a standalone language that must be parsed from source text before a program can work with it. Importantly for this example, an external DSL encourages a minimum of syntactic noise, and can be read without any program compilation.

The example questionnaire DSL looks like:

Above is a two-step questionnaire that collects personal and employment details.

• Each section has an id, a title, and a list of questions.
• Each question has an id and some prompting text.
• The declaration of a question id (e.g. #months) can be prefixed with a symbol to indicate what kind of data is being collected – the pound sign/hash in this case denotes a natural number.

The application will read the questionnaire definition associated with a particular kind of account request, and present the steps to the user in a wizard-like interface.

Approaches to Parsing the Questionnaire Definitions

Parsing is the process of taking text in a source language, like the questionnaire above, and converting it into a representation – usually some kind of object model – that a program can work with. For the C# programmer, there are several ways to achieve this.

Hand-built Parsers

The very simplest as well as the most complex parsers are often built by hand. The simple ones because the solution is readily evident to the programmer (e.g. “split the string by finding commas in a loop”) and the most complex because the programmer needs an extreme level of control (e.g. the C# compiler.) Parsing anything in between by hand is usually more trouble than it is worth, unless you’re really into languages and know what you’re doing (that definitely rules me out!)

Regular Expressions

These are a convenient way of matching and extracting patterns from text. .NET includes the built-in System.Text.Regex class for working efficiently with regular expressions, so they’re usually the first option to consider when faced with a parsing task. Beyond quite simple grammars, regular expressions rapidly become hard to read and maintain. This is perhaps the biggest of their shortcomings, but there are also many grammars that regular expressions are unable to parse (starting with those that allow nesting.)

Parser Construction Toolkits

Industrial-strength parser construction toolkits and ‘language workbenches’ allow a grammar to be specified in a declarative format. The toolkit includes build-time tools to generate classes in the target programming language (e.g. C#) that can parse the grammar. Using such a toolkit requires an investment in both learning how the toolkit works, and integrating it into a project’s build process. For small parsing tasks this can be overkill, but for anything of significant complexity or requiring high parsing throughput, learning and using to use such a toolkit is highly recommended.

Parser Combinators

This function-based technique is often used by default in functional languages like Haskell and F#, both of which have high-quality parser combinator libraries. C# also has a fledgling combinator library called Sprache, built by yours truly and used in the rest of the article. Sprache makes it very easy to write and maintain simple parsers, without a steep learning curve or build-time tasks. It fits very nicely with a test-driven development process. The drawbacks are currently speed, efficiency and sometimes the quality of error messages – none of which is a big deal when parsing simple DSLs.

Getting Started

First, download Sprache.dll. This article is organised in such a way that you should be able to follow along with the text by creating and testing parsers in Visual Studio with NUnit or similar.

Grammars are built from the bottom up. First, parsers are created for the low-level syntax elements like identifiers, strings and numbers. We then work upwards, combining these basic units into more complex ones until we have the complete language.

Parsing an Identifier

In our questionnaire definition language, the most-nested significant element is the question:

The basic parts here are an identifier an some quoted text. The first task for our parser will be to parse the identifier, in this case ‘name’.

Parsers in Sprache are static methods on a class representing the grammar. QuestionnaireGrammar.Identifier is of type Parser<string>, i.e. it returns values of type string from the input.

The definition of the parser is:

This reads fairly well – we’re going to parse a non-empty sequence of letters and return the text representation of those letters. The elements of the parser here are:

Parse.Letter – the Sprache Parse class contains helper methods and properties for common parsing tasks. Letter is a simple parser of type Parser<char>, that reads a letter from the input and returns it as a char. If the next character on the input isn’t a letter, this parser won’t match.

AtLeastOnce() – all parsers created by Sprache support repetition this way. AtLeastOnce() takes a parser for a single element of type T and returns a new parser that will parse a sequence of elements, returning IEnumerable<T>.

Text() – the AtLeastOnce() modifier took our Parser<char> and converted it into a parser of type Parser<IEnumerable<char>>. The Text() helper function takes a parser of IEnumerable<char> and converts it into a Parser<string>, so that the result is more convenient to work with.

Token() – finally, the token modifier accepts then discards leading and trailing whitespace.

Simple?

There are a couple more tests we might be interested in for the Identifier parser.

A Sprache parser will parse as much as it can before returning. In this test case the parser will succeed, but won’t consume all of the input. (Later we’ll see how to make assertions about end-of-input.)

The Parse() extension method throws ParseException when the parser doesn’t match. You can alternatively use the non-throwing TryParse().

Once we’re happy that identifiers are being parsed correctly we can move on.

Parsing Quoted Text

Quoted text isn’t much harder to parse than an identifier – our basic version doesn’t support escaped characters or anything fancy.

Looking again at the input:

To parse the quoted text, we need to match:

1. The opening quote
2. Anything except another quote
3. The closing quote

The quotes themselves aren’t particularly interesting to the program, so we’ll return only the text between them.

One test for the parser will look like:

Jumping straight to the parser:

This opportunistic repurposing of the Linq query comprehension syntax was first described (AFAIK) by Luke Hoban from the F# team. The from clauses lay out the individual units of the syntax, while the select clause transforms them into the return value of the overall parser.

Parsing the Question

You’ve probably noticed by now that parsers are strongly-typed: a parser for a character returns char, and a parser for text returns string. A parser for a question, will return – Question!

This is a great strength of combinator-based parsing when constructing DSLs. Once a semantic model for the problem has been built, the parser can translate input directly into it.

A unit test for a basic question now passes:

Parsing a Section

Parsing a section is just like parsing a question: first we build the semantic model, then use the existing parsers to translate the source text.

Remember a section looks like:

We can represent this in the object model as:

Building a parser is as easy as building the object model:

To complete the example, we have one more model class to define:

Its corresponding parser (this time without the comprehension syntax):

By affixing .End() to the parser, we require that the full input is parsed (i.e. there’s no trailing garbage.)

That’s all we need for the example without any data type qualifiers.

Supporting Answer Data Types

The finishing touches of our grammar add support for the answer type qualifiers.

We can use an enumeration for the possible answer types.

This is a pretty limited set, so by brute force we’ll check for each possible qualifier.

The Question object is modified to accept an AnswerType as a constructor parameter, and a simple modification of the Question parser completes our work.

Summary

The complete parser is just six rules, totaling about 25 nicely-formatted lines of code.

While robust parsing is a non-trivial task in the real world, I hope this article shows that there are simple, low-friction options that fill some of the gaps between regular expressions and language workbenches.

In the Autofac 2.1 MVC integration, there is a new ContainerBuilder extension method called RegisterControllers.

The reason for the switch is that RegisterControllers is a thin wrapper around the new assembly scanner, and supports the same syntax as the rest of Autofac’s registration methods: