In the overview we talked about breaking ones application into parts, well that neatly corresponds to the makeup of nRoute’s core features. The figure below shows that we have three sub-frameworks, and built upon them are a number of core features:
Now, as an end-user of the framework you’ll normally not concern yourself with the ins-and-outs of the sub-frameworks, but it is good to know what they as they form the basis of the core-features that you would directly consume.
The Routing Engine is what it says it is – or more precisely, it takes in a Url and returns you a registered handler against that Url. Simple as that; plus, it is agnostic of what the handler does, which means it is extensible and you can easily build
your custom feature atop it. Within nRoute we have the navigation and (MVC-like) controllers features built upon the routing engine, which are represented above as “Navigation Services” and “Controller Services”.
Having a routing engine in a client-side application might seem odd, but Urls allow us to abstract content, actions, and other consumables in a very portable, easy to use, and loosely-coupled way. And this kind of “addressable abstraction” is
a well-understood approach used by consumers, enterprises and systems day-in day-out. Moreover, in terms of sophistication nRoute’s routing engine is actually a port of ASP.NET’s routing engine – so it’s quite robust and fully-featured.
One of the necessitates of separation of concerns is that you want loose-coupling – one way to achieve that is to use a common intermediary, using which you are able to shed direct references. And so no surprises, in nRoute we have a pub-sub type messaging
framework that acts an intermediary to relay messages within your application. By design it’s a highly efficient, strongly typed, and multi-threaded implementation based on the observer pattern. Or more specifically, the API for it is based on
Rx-framework’s interpretation of the observable-pattern (vis-e-vie their IObservable<T> and IObserver<T> interfaces), which as a major buy-in avails the full range of Rx-framework’s
operators for use with messaging in nRoute.
Resource Locator Framework
As the name Resource Locator Framework (RLF) suggests its idea is to locate resources, or more specifically it is an Inversion Of Control (IoC) cum Dependency Injection (DI) component. However, it is different from traditional IoC/DI components in that it
allows each type of resource or dependency to put in place its own materialization strategy, and two it is designed to be extensible and open-ended as opposed to being internalized and closed-looped. In more ways than one, its approach is quite similar
Managed Extensibility Framework (MEF), however they not equals as RLF offers a much higher degree of customizability with fine-grained control over each and every resource/dependency.
Within nRoute RLF forms the basis of many open-ended features like Services, Modules, ViewServices, ViewModels, etc. so it's really used quite extensively and is for all practical purposes ingrained in the approach nRoute takes towards composition. Having
said that you normally don’t have to concern yourself with the nuts and bolts of RLF, though you will most definitely employ its attributes driven approach to annotate bits and parts that make up your application.