Architecture for dashboard

Question

I'd like to know if my Architecture idea, is the best approach following some pattern.

I'll create a Dashboard for my company, and I never will delete or update data in my database, just read the data from database.

Nowadays we just work with our SQL Server database, but I want a solution that will provide a easy way to implement a new feature, like a new database compatibility.

THE APPLICATION

This is a dashboard for all my clients, where I'll get the data from my database server making a filter for his company, and then plot some charts and show informations about her rentability, financial information, etc.

Will be web-based and must work in any screen size (smarthphones, TV's, desktop, etc).

I want to use NHibernate as ORM

IDEA

My idea was in the user interface, use MVC 4 Web Application and all request from the User Interface to my Business Layer will be through REST.

My Business Layer it's a MVC Web API, to desacouple the User Interface from my Business Layer.

The Business Layer will access Repository (Repository Pattern), with CRUD operation (in my case it's just 'SELECTS' because I just need show the data, never update, never insert).

It's a DDD approach, working with NHibernate.

Sometimes I think it's to much for a dashboard, where we can't insert nor update data.

I'd like to know what are common architectural pattern for this problem.

I said some pattern's here, but maybe someone with more experience then me could see a better approach to this kind of application.

Answer 1

User Interface

The requirement for working on a range of devices from smart phones to desktops is addressed by two different approaches:

• Recognize the type of device and produce a different site page for phones versus desktops. This often yields funny results on large tablets. Not funny in the good sense.
• Use strong dynamic layout with cascading style sheets to position items on the page based on screen size and resolution. This yields very usable, scalable sites. They also work quite well when users want to rescale the browser page on a desktop. Here is a good discussion.

The dynamic layout approach then suggests that you organize your dashboard into a set of UI widgets. Each widget would have a set of graphical elements, fixed textual elements, dynamic text and dynamic graphical elements. The widget is then tied together with scripts that properly display the widget as well as querying the back end for data.

Client Back End

As you have already identified, your server back end would be accessed by REST requests initiated by individual widgets. Each REST request would be essentially stateless. That is not to say that you wouldn't store your client profiles and user profiles in such a way that you couldn't always determine that any particular web application can only see exactly what it should see.

Each widget needs to periodically get updated data from the server. It will poll the server using a REST request passing the parameters configured into it as well as a session ID used to authorize access to that data.