As mentioned previously, Server Procedures usually implement all of the elementary processes. There can be many factors involved in deciding on how many server procedures are required and what processes are implemented in each procedure. As a starting point for this discussion, you can usually expect there to be two server procedures for each entity type in your model (although we will not be doing that for all entity types in this tutorial). One procedure will contain all of the processes dealing with a single entity of that entity type, and the other procedure will contain the logic necessary to provide a listing of entities for that entity type.
Two factors influence this decision. One is that you would normally create procedures for processes based on the processes having similar view structures. The other is that in a typical client/server application, you first select a single object to be edited from a list of those objects, and then you would edit that single object.
With this as a starting point, we would expect our application to have four server procedures:
Thinking forward to the workflow and presentation for this application, we can probably dispense with the List Golfer procedure step. It would probably be required from a Customer Service standpoint, that is, a customer calls in and cannot remember their password, so our Web site's Technical Support personnel would have to look the customer up from some sort of a list. Initially, we will not provide this functionality. We will create just three server procedures. However, if we eliminate this functionality, we introduce another small problem. Typically, we get all the attributes of the object we want to display to the user for updating from the list procedure. If we eliminate the list of golfers, then we have to get the attributes to display for the update of golfer from somewhere else. We can easily solve this problem by slightly modifying the Login Golfer elementary process.
|
Copyright © 2013 CA.
All rights reserved.
|
|