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.


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


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.

  • So far, you have identified some technologies and some things you aren't going to do. You haven't told us what or who the dashboard is for, how responsive it has to be or anything else we could use to help you. Commented Aug 6, 2014 at 15:07
  • @BobDalgleish This is a dashboard for all my clients, where I will get the data from my database server making a filter for his company, and then plot some charts and show informations about her rentability, etc. Will be web-based and must work in any screen size. I said some pattern that, in my mind, could be a good approach but maybe someone with more expertise then me, can think in another way to a better approach. Commented Aug 6, 2014 at 16:37
  • How dynamic is the data to be displayed? How often does it update for a particular client? Are there sudden changes or breaking news that needs to be displayed? Are updates periodic or episodic? Is each portion of the dashboard independent of each other, even if they use the same data sources? Commented Aug 6, 2014 at 19:06
  • We have big clients and small clients, but even the big one haven't such dynamic data. Isn't a Real Time dashboard, today I'll show the data from yesterday, like, which was my best seller yesterday, etc. No breaking news nor sudden changes. Updates in those data are episodic. Each part is dependente because our database has a BI approach, with Facts and Dimension, so the Revenue chart has a relation with my Financial chart because these charts will consume data from the same table Commented Aug 6, 2014 at 19:18

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.