In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.
Part 4: About logic on the client
At the end of part 3 I asked you to imagine that your hypothetical enterprise application is well structured and consists of several components that implement the business logic. These components can be accessed through some remote interface. Further, the ui layer is implemented as an individual program running on a pc. It could call the business components through some remote procedure call mechanism. Should it?
If you found this question misleading, you are certainly right. Of course it should. To some extent. The underlying (hidden) question is how much logic is allowed or wished for on the client.
Consider this: who should take care of the orchestration if several remote procedure calls are necessary to complete a business function? Who is in control of the page flow or navigation? Where does validation of user input take place? How much does the client know about data types and dependencies among fields on a form? To answer these questions we need to decide how thick or thin, rich (or poor) the client should be. Especially the term thin client is used in several ways. To escape ambiguity I prefer an alternative means of distinction: business logic vs. presentation logic. The first one drives the application, it is a manifestation of its use cases. Presentation logic, on the other hand, drives the user interface. It is generally agreed upon that within distributed systems no business logic shall be present in the ui layer. One reason is that you would loose functionality if you exchange the client. Presentation logic is specific for each type of client. Hence it seems natural to put it in the corresponding layer.
If the client knows the page flow and knows which forms will be displayed along the way it can do so without bothering the backend. Of course, at some point it will need to persist user input or invoke a business function. Certainly, final consistency checks must be performed by the backend even if the client knows how to validate input. But if the client is self-sufficient to some extent it spares us server roundtrips. Something that may be crucial for mobile apps.