|
|
Posted by C. (http://symcbean.blogspot.com/) on 12/30/07 20:34
On 29 Dec, 18:51, "Pugi!" <pugin...@gmail.com> wrote:
> Because my functions tend to become rather lengthy I split up the
> functions for each subject or action in a function (a) that checks
> user input (filter and validation) and if this checks out ok it passes
> the variables to another function (b) that retrieves or stores the
> data from/in the database, function (a) then communicates the result
> (true, false, error, list with data) to the client.
> Currently I organized all functions per subject (all functions that
> handle for example 'groups': get, add, modify, delete in a file) and I
> include all the files when the webservice is called, this is over 500
> kB.
> A different approach would be to only include the functions needed,
> this means a file for each function, so a lot more includes.
>
> What is a good approach ?
>
> Pugi!
You're currently loading 500 kB of code for every request? That's not
good.
Firstly, even if you are running a webservice, a front controller
architecture undermines on of the fundamental concepts of HTTP -
addressability. There should be multiple entry points for different
areas of functionality.
Since you seem to be taking a procedural (or possibly) functional
approach to programming, IIRC the autoloader functionality will be of
no benefit.
Without knowing what your webservice does and what interfaces it
provides it is difficult to say how it should be split up but I'd say
you should definitely be looking at conditional includes based on the
entry point or request details and splitting up the functionality to
get the optimum number of files (e.g.
- one include file for soap parsing and input validation,
- one for database connectivity/dbms abstraction
- one which interfaces to the request specific include files (below)
and generates the output
(the above would be included every time)
- one for adding records of type 'A'
- one for deleting records of type 'A'
- one for updating records of type 'A'
- one for adding records of type 'B'
....
(note that although validation should be done at entry, encoding
should be done at the point the datum exits PHP to be written to the
browser or the database or somewhere else.
C.
Navigation:
[Reply to this message]
|