Did you hear about CQRS? Are you using it?
We, at Selise, are building a large enterprise application with CQRS. I would like to share some of my experience with it.
I would take a moment to explain it first in really basic words, you can checkout and dig more later. The core principle is CQS - Command Query Separation which tells you to separate your data read and data write operations. The method returns data should not modify the data, on the other hand the method that modifies the data (like inserting, updating or deleting) should not return any data. Which means your AddNew Method cannot return the newly added row ID back to you. CQRS ( Command Query Responsibility Segregation or Separation) is an application CQS concept. We can call it a pattern. Its not an architecture or framework.
To go a bit deeper with CQRS lets agree to some arguments.
Argument 1: In any large user base application you will have more read than writes.
Argument 2: Reading data to display in the UI from a normalized database is slower than a denormalized database. Joining and retrieving data is expensive, its much faster if you could retrieve all your UI data for a single page as a collection row from a single table of the database without joins. The structure of this table should be more like the View-Model of your application.
Argument 3: When user modifies a data, it is not always necessary to synchronously update the database. We can live with some delay and let the database change happen asynchronously. Update of the UI also could be asynchronous. For example while adding a new row to a grid, the UI to add item could make an async request to server to add the row and UI can get back to grid. The grid seems to be not showing the row which just now has been added but the UI is responsive, you can make another add row or click on a different link meanwhile. If you are still at the grid, after a few sec the row appears.
|Asynchronous database operation|