Oxite, as an MVC application, has three core layers. The Model layer includes the entity classes, the services, and the repositories. The Controller layer includes the controllers as well as the filters which work with the controller to process the request.
The View layer includes the views, the partial views, and some helper classes and uses the data passed from the controller layer to render the page.
We have six projects in the solution. Each roughly corresponds to a different layer of our architecture.
This project contains code related to routing as well as the model and services. It also defines the background services that Oxite runs and our configuration classes. It defines but does not implement the repositories.
This project is a DB Pro project that contains the schema for our default data provider. You can't open this project with an Express version of Visual Studio but a solution file is provided that does not include this project so you can use Express.
This project contains implementations of all the repositories and uses LinqToSql for data access. Currently it doesn't map the database directly to the entity objects but rather to an intermediate set of objects which are then translated into the standard
Oxite entites. This is one of the areas we're looking at changing in a future release.
This project contains all the code for the controller and view layer. It has all the controllers used by the site as well as the various view model classes used for communication from the controllers to the views. It also contains the WCF service used to provide
the MetaWeblog API.
This project defines tests for the entire solution. It uses xunit as it's test framework and needs it to compile.
This project contains the views themselves and the web.config file that defines the site. No C# code is in this project but is in Oxite.Mvc instead.
Oxite uses Unity as it's dependency injection container. DI is used to create virtually every object in the system that requires services. We use constructor injection exclusively so all a component needs to do is specify it's dependencies on it's
constructor and it will get them at run time. Rather than use a static service locator, objects that need to dynamically create other objects, for example the Controller Factory, simply include IUnityContainer as one of the dependencies.
Most of the registrations occur in the OxiteContainerFactory class. This class sets up all the defaults for our container by registering the default implementation of our services as well as a few key instances like the routing table and the site configuration.
We also add all the connection strings found in the web.config file to the container so that they are available for injection into our data provider. That data provider as well as the repositories reside in an assembly that Oxite.Mvc does not reference and
therefore cannot register with the container via code. The web.config file contains a <unity> section where the repositories and the DataContext are registered. This also provides a way for you to override any of our in-code registrations as well as
add any registrations you need for your additional components.