|
|
Posted by Leila Lappin on 10/20/08 11:19
When I worked with other OO languages, I usually designed my persistent
business objects in two levels. A level (lower level) designed and
implemented direct database calls. Each database table had a class
abstraction at this level which provided the database calls for saving,
loading and etc. At this level I also provided for the caching
considerations, i.e. if a table was already queried and a list was available
the list in memory was used instead of querying again.
The next level was where the business model was implemented. If a business
object required information from three tables that related to each other in
a certain way the load methods would access the objects from cached lists in
three different classes (each representing a database table) and created the
final list. At this stage the list was cached and also represented the
business logic.
Although I haven't done this in PHP I think with PHP5 it's possible. The
only challenge may be the caching of query results but I think Pear modules
already have something about that.
-----Original Message-----
From: Richard Lynch [mailto:ceo@l-i-e.com]
Sent: Wednesday, June 22, 2005 9:14 PM
To: Evert | Rooftop
Cc: PHP-Users
Subject: Re: [PHP] Extra (persistant) tier
On Mon, June 20, 2005 11:44 am, Evert | Rooftop said:
> I'm writing a big web application, and trying really hard to seperate
> business logic and presentation, which been no problem up to now.
> Because I abstracted the business logic so much the framework became
> heavier, sometimes a simple action can take up to 2 mb memory and
> several extra milliseconds.
Perhaps you have abstracted the business logic in an inefficient manner...
It's real easy to get carried away making a ton of objects that look real
purty in the abstract, but are really just clutter when you get down to
what you want the application to *DO*.
Take a break from it, step back, and try to look at it "sideways"
Sometimes the "obvious" set of classes is actually not the "right answer"
I don't know how else to describe this...
> I know this doesn't sound much and I'm applying all kinds of technique's
> to reduce resource-usage and increase speed. The thing is, I feel like I
> need to split the business tier up in 2 tiers, one of them being my
> persisitant object manager. The main reason is because every script that
> is executed must do some initialization and database calls, and I think
> I could reduce this by making a persistant tier, but there doesn't seem
> a good way to do this using php except when I would use sockets.
I don't think you are going to get the database connection to persist
across scripts, period. You can use _pconnect so that the database server
will re-use a connection data structure, which can improve performance.
The penalties for _pconnect are memory and number of active connections.
Each persistent connection will chew up a little bit of memory.
The way it works out, each persistent connection ends up being tied to an
Apache child. So you *MUST* configure your database to have *more*
connections active than the number of Apache children. You want a few
extra so you can still use mysql from shell or mysqladmin to bring down
the server if you need to. You do *NOT* want to be locked out of
mysqladmin because all the connections are tied up in Apache children.
[shudder]
If you really have a good chunk of semi-static persistent data, you should
consider moving those into a PHP Module by re-writing the data load in C.
> Shared memory doesn't really seem like an option, because I would still
> need to include all the classes to manage it, and when I use shared
> memory, the memory would still be copied into the php memory + having a
> central manager seems like a good idea.
Perhaps the data wouldn't *ALL* need to be copied into each PHP Module,
but some of it could be accessed on an as-needed basis.
> I know I'm pretty vague in my requirements, but I think it should be
> enough to explain what kind of solution I´m looking for, because this
> seems like a big advantage of java over php, or am I mistaken?
> If you have any ideas, let me know :)
I dunno how stable/mature the PHP/Java interface is, but maybe it would be
an option to move the semi-static data into a Java object... Though you'd
probably be even slower to get that data to/from PHP then. Worth checking
out other's experience, or even a quickie trial run if you can hack up a
test for a benchmark.
Maybe (gasp) Java is what you should have written this in in the first
place.
OTOH, maybe you shouldn't have gone the route of Object-Oriented
abstraction of business logic. If blazing speed is the requirement,
that's not gonna be the answer, most times. A well-designed procedural
body of code will generally out-perform OO and can still have sufficient
separation of business logic from presentation logic. YMMV
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Navigation:
[Reply to this message]
|