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@xxxxxxxxx] Sent: Wednesday, June 22, 2005 9:14 PM To: Evert | Rooftop Cc: PHP-Users Subject: Re: 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
