LinkedIn: Isolation Business layer from UI - Does it make sense?
This is a great question, but I have the completely opposite answer: I am a passionate Data/Business/UI separation believer, because it payed back in the long run.
All IT systems work with data items.
Some of these items are persistent, and stored externally to our system, in files, databases, etc. Others are also external, but changing: coming from a clock, sensors, ...
There are "worker" items in our system: database connectors, printing engines, GUI frameworks, etc. They have a complex, generic business logic, like managing SQL queries, etc; their "data content" is their configuration: location and access to the database server, the location and format of a data file.
We also have assistants, they help the user work with our components, like selecting the proper parameters for a process; they "stand behind" the more complex GUIs.
All items communicate with each other via messages which are temporal data items themselves.
Data layer is responsible for the interaction with those external data and event sources: from databases to home automation gadgets; its task is to reliably transform their information to our business data entities (Person, Door, Truck, etc.), manage the update transactions.
Business is the behavior of these items, this is where we implement the "knowledge" of our system. Key elements are the "plain data" items. They have no "activity", but they must ensure their consistency, and provide a status report (and not a single first error message or exception). You can put anything into these data items, but as long as they report any error, you can't use or save them. You can drop a featherweight GUI on each data item in this way: edit all fields and let the data item complain - or build a complex one, where you manage the underlying data elements' states and add your own messages.
Workflow is just another generic task: you can create a workflow engine that plays by its configuration. Or wrap one of the many existing engines.
If you do this, GUI gets relatively simple: you need a framework that connects the widgets of the current platform to the data objects, and let the user play with it. (It was one man-month for me in GWT, after I had the data framework.)
Complex for the first glimpse, but look at what you get:
- the more you connect your logic to the actual GUI framework, the more pain it means when you have to change it (move to another platform or adapt to a new version);
- you can use the complete system without the GUI, so instead of a complex GUI simulation engine, you can run tests or do mass processing tasks;
- there is a simple way to log the user actions (a very pleasant feature in testing or bug hunting);
- and the ultimate goal for me: transparent system structure! In the long run, all systems change like our bodies, the only question is how much work it takes to keep it in coherent state.
I have created such things in closed source environments, so unfortunately I can't show you actual codes, but I have to tell you: it rocks :-D
(Even though I could not find anyone "above" who could understand it, so I quit my job right now...)
I am not so keen on popular terminologies and technologies (seen too many already), I would rather like to understand what and why we (architects) do.
For example, we have a database.
Yes, we could do everything directly in SQL, typing commands, creating scripts, giving the user an SQL console - but we don't. We prefer using our own terms (like C++ or Java classes and objects), so we create a layer that wraps SQL communication and shows us our objects.
Yes, we could allow the users to do anything with these objects and instruct them how to play nice - but we don't. We add our knowledge to the objects so they can report on their states, and we can protect our system against incoherent states or illegal usage.
Yes, we could just drop these intelligent objects on the screen for the users to do something with them - but we don't. We assist users so they can learn working with these objects when they use the system, by showing them the next possible moves, and the steps they should do to set up a valid operation - and hide information and actions they have no rights to see or execute.
Dmytro, you asked if Navigation is business logic. My answer is: yes, definitely. But for me this does not mean moving the BL layer "up", to the GUI surface, but the opposite: the "assistant logic" should go down and share the same place as the lower business logic components like consistency checkers.
The UI should be feather-weight: only displaying information from the Data and the Control objects, reflecting to their changes. Data means displaying the selected printer, Control means the list of settings tab pages for that printer, the list of missing required parameters, or the actual pageID to display on the Next button, depending on the current data values.
When it comes to a remote desktop, message-based communication comes very handy again: it allows transparent proxy communication between the server and the client. In most cases, that is inevitable for platform or security reason: you can't have the same functionality in a web browser as in a "fat" client; you can't access the database server from a client machine directly; you can't access the administrative user account which is used to accomplish your requests on the database. It also allows you "batching": sending multiple requests to the server, or allows the server to send client information that it perhaps did not even asked.
