Service Locator v.s DAO

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Service Locator v.s DAO

Post by alex.barylski »

I'm just reading up on Service Locator...sounds like it would be useful in stateful applications such as Desktop applications, but I'm not sure I'm seeing how it would be used in web context, seeing how connections and resources as such are destroyed at script completion. There is certainly no performance benefit in caching resources for later use (if I understand the pattern properly).

I can see how by decoupling that kind of code from your main index.php might help keep code slightly clearer, but...

Assume I have a application which uses CSV or AdoDB:

Do I use a service locator to abstract the data source or would a DAO make more sense?

If I understand correctly, AdoDB is already something of a DAO as it provides a consistent API to manipulate all SQL storage engines, but what about CSV? The connections are quite different. Open files and working with handles as opposed to SQL engine handles...

If I were to implement a DAO for SQL and CSV (XML, etc) would I basically have to first detemrine the API and basically use a service locator to set the connection contexts and manipulate the data source via the DAO API?

Wouldn't I already be wrapping a DAO (AdoDB) with another DAO (AdoDB, CSV)? Adapter pattern???

Obviously a single large DAO which provided an API for an entire application would be *heavy* overkill so grouping according to class would make sense - hence the use of classes I guess eh? :)

I should note, I'm actually leaning more towards the use of a procedural DAL (data access layer) for CSV and SQL but the connection configuration is where I am struggling slightly - which is where I think a service locator might come in handy. The reason for this is performance. Instantiating a object for accessing a database or CSV file, when there is likely no member data associated seems awfully wasteful. Simple function calls seem more appropriate, but where in the application do I setup the DB for usage or open the required CSV files - service locator anybody? :)

Thoughts, suggestions, example code of what each might look like???

Cheers :)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

I'mnot sure who has the terminology mixed up, but I've always thought a Service Locator was an object fetching tool/pattern, not a datasource locator? e.g. use of __autoload($class) is a Service Locator.

Sounds like (to my ears) you need to lookup on either O/RM or Strategy pattern?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Service Locator is basically a class locator in its most basic form - __autoload() in PHP is a basic example, but it can be extended in a few different ways using Factories, for example.
Do I use a service locator to abstract the data source or would a DAO make more sense?
Both are different patterns - a DAO (ADOdb is an abstraction layer not a fully functioning DAO) helps with mapping objects to a datasource. Service Locators locate and retrieve services (classes basically). Both can be used in combination of course.
Post Reply