I have been asked to write the same type of interfaces and this is
what I have been told/learned.
I believe what you are referring to is the "database layer of an application".
I have seen this called the "Data access layer (of an application) also:
http://en.wikipedia.org/wiki/Data_access_layer
http://www.paulgrenyer.com/Integration_Testing_A_Java_Enterprise_Application_Data_Access_Layer.pdf
1. In order to have efficient data access
the underlying database objects
themselves have to not have performance related issues.
E.G. If you are using tables, the tables should have appropriate
indexes, the statistics on the tables have to be up-to-date,
and if you don't need the most recent data in the table,
it is a good idea to consider using materialized views.
This seems obvious, but make sure you have access to the database
itself and the database doesn't have any problems of its own,
E.G. too many outstanding sessions, I/O problems, etc.
2. In the code for the database access,
it is a good idea to
avoid hard parsing and using bind variables
will help avoid this.
3. If the work that is done in your data access layer
consists mostly of short lived transactions it may be a good idea
to use connection pooling. I have
http://www.javaranch.com/journal/200601/JDBCConnectionPooling.html
I am not sure whether the class you are using will work/is designed
for connection pools but if you are using a Session object (usage
of getDefaultInstance leads me to believe this might be a Session
object) and you are using this for Hibernate then this URL does state
it will work with a connection pool
http://docs.jboss.org/hibernate/orm/3.5/api/org/hibernate/Session.html
I have a feeling you could be using a different object - the object
documentation should state whether it uses/is compatible with
connection pooling
4. This URL states getDefaultInstance will always create
a new object and there are alternatives. I am not sure if that is
what you want - it is something to consider
https://stackoverflow.com/questions/4184204/what-is-the-difference-between-getdefaultinstance-and-getinstance-in-session
Again I apologize I am not sure if this document is actually for the
class you are using - this is just a best guess.
Given the uncertainty of my answer, I make it a community wiki. Feel free to edit it.
It depends on the abstraction level you use. One way is to be language-agnostic. Here's an example of a sequence diagram:
Source: UML Sequence Diagrams Examples
As you can see, the diagram encompasses both client-side and server-side. Applying the same to a communication diagram would be harder, since communication diagrams have generally a smaller scope, but it's still possible.
The major factor to take in account is what is the purpose of your communication diagram.
One possibility is to use a communication diagram to show the entire process. Such diagram may be language-agnostic and mix several parts of the system or layers within it.
This is suited well for an overall view of a system in a highly abstract way. It may be used, for example, to give a general idea to a new developer of some complicated stuff which happens between a client and a service, between JavaScript and server-side language or between a consumer and its API.
If your company has a single developer who does both client and server-side programming, then such diagram may be useful to him.
Another possibility is to use a communication diagram to show precise flow within a layer of a part of a system. Here, other parts and layers would be interpreted as black boxes which communicate through interfaces.
This is suited well for a detailed view of communications flow within a system. For example, a JavaScript developer cares about communications flow happening in the browser, but doesn't care about server-side stuff. In the same way, a developer of an API won't need to look at the communications diagram which explains how a client of the API is dealing with the different messages.
If your company has dedicated client-side programmers and dedicated server-side programmers, they would probably favor this sort of communication diagrams (which doesn't exclude that they should also have a good overall view of the whole system.)
In practice, I've never seen communication diagrams so general that they would encompass for example both client and server-side. I don't think it's wrong to do such diagrams, but it's not a common practice.
Edit: I talked with a colleague more experienced than I in UML; his suggestion is to create two communication diagrams, one for JavaScript, another one for server-side. Mixing both would make the diagram more complicate than it needs to be, and some people may not understand which step is happening where.
So unless you are sure that having a single diagram would benefit you, stick with separate diagrams that you can put side by side for an overall view.
Best Answer
It is pretty common in PHP Projects to have some kind of Data Abstraction or Data Access Layer. Simply because of DRY Principles and cleaner error handling. Experienced Programmers don't like to repeat themselves over and over again and they seperate domain logic from data manipulation as much as possible.
There are lots of very good Frameworks and components out there to help with Data Abstraction or even Object Relational Mapping, see this Post at SO.
You might experience what lots of other code reviewers experienced before:
(from: http://www.osnews.com/story/19266/WTFs_m)