Getting it right the first time
We all know that architectural decisions affect the whole system and that they often need to be made early in the development process. It means a lot of effort if you change that decision a couple of months later.
Good architecture is one that allows an architect to make late decisions without superior effect on efforts and costs.
Choosing your religion(s)
There are many technologies in the wild. Hunting the right ones down can be quite a hassle, but they are the cornerstone of a good architecture. We have brewed a fine concoction of technologies to minify the “choosing is losing” factor.
- WCF (OData)
- ASP.Net MVC
- ASP.Net Web API
Dressing in layers
Another fundamental cornerstone of a good architecture is the use of layers, thinking of browsers and other clients in a dynamic web development architecture.
Browsers are the nastiest clients within this layer, since browsers come in many flavours. Not all browsers or their versions support the client side technologies. Even when they do, there’s no guarantee that they behave the same way. Using libraries that handle these inter-browser differences are a must too as staying as close as possible to technology standards.
When it comes to technologies for this layer, jQuery is the best library that creates a standardized layer on top of these inter-browser differences.
Scripting is only one part of the story. HTML is another part. Since more and more browsers support the new HTML5 standard (which won’t be a final standard for a while), new possibilities for a richer UX and a broader spectrum of devices arise.
Other clients can be broken down into 2 groups: the trusted and the untrusted. Trusted applications are allowed to access the Applications Server layer. For untrusted applications, it’s a better practice to expose some kind of Web API that is deployed on the Web Server layer.
On the other hand, this layer exposes and submits data back and forth between the browser and the Application Server layer (which is discussed later on), either through ASP.Net MVC (for our website or other clients) or through a custom made Web API (for the untrusted apps).
Two important considerations. We prefer the partial (ajax) calls between a browser and MVC to return rendered HTML, in stead of JSON or XML. Communication between untrusted apps can be accomplishing y using the REST (Representational State Transfer) approach.
Trusted apps may circumvent this layer and directly access the Application Server layer for their data-needs.
The application server is responsible for exposing the data through various technologies. These technologies can be segregated into 2 groups: read-only and read-write.
Question is, do we need this separation?
Retrieving data can be pretty straightforward.
One requests information and the information is retrieved from the data store and is relayed without further ado. For this type of communication OData services and REST services are interesting since they offer, among other things, great flexibility for querying.
When it comes to storing or removing data, often extra business logic is required. In that case we need to fall back to our beloved WCF-technology.
Putting the pieces together
Now that we have all the pieces, it’s time to fit them all together:
- OData- & Rest services
- Web API
- Smart/trusted Apps
- Stupid/untrusted Apps
In the bottom layer, we have application services, which form the Application Layer of our architecture. As discussed earlier, there’s a read-only service provider (OData) and a read-write service provider (WCF).
The layer on top of the Application Layer can be divided into 2 groups: web-based clients, which represent the Web Server Layer and smart/trustworthy apps (preferably developed by the service providers themselves). The Web Server Layer components act as a kind of gateway for our application services.
And then, we have our browsers and other stupid/untrusted apps which can’t directly communicate with our Application Layer.
Last but not least
This architecture offers a guideline that can help with deciding what technology to use and what place it will take within the grand scheme of things. But always keep the balance between YAGNI (You Ain’t Gonna Need It) vs. BDUF (Big Design Up Front)!