UI Data Query A Cross Cutting Concern?
Rehein makes the interesting argument that there is no clean separation between the presentation, business, and data access layer. Instead, UI concerns often known only at runtime like paging, filtering, sorting, and so on make data querying a cross cutting concern. He therefore, recommends we stop creating UI interfaces like:
GetInvoicesForUser(int userID)
This is too inflexible and we end up breaking or overloading these interface methods every time a new need comes up:
GetInvoicesForUser(int userID, int pageNumber, string orderByColumn)
The goal is for any interface implementation to be open for extension but closed for modification. But by insisting upon a hard separation of concern between the UI and the business/facade interface we're making modifications left and right.
My name is James Still and I'm a seasoned software developer living and working in Oregon USA. I'm an avid cyclist, backpacker, reader, stargazer, and I pick at the guitar from time to time.
1 Comment
Ed Chapel said
Filtering of queries from the UI is a real conundrum here. EntityFramework hides this concern from you (in a rather concerning way). I do appreciate how NHibernate makes you much more aware of the problem. I suggest a distinction should be made for the type of UI presented. A data grid is a purely data-driven view of the application to which I agree with you -- and Ayende's -- assertion. It is not much different from SQL Query Analyzer. Once you go to a workflow-driven model, I would argue that keeping the DAL far from the UI is more cohesive design.