How can I implement to be reusable

[djsmithme]

But if you app was successful you would now have a another problem to deal with. SQL is a

special-purpose programming language designed for managing data held in a relational database management system (RDBMS)

So it’s already the right tool for the job no? I’m bias. I love SQL, I find it easy to read and it’s easy to port to a range of languages. An ORM has a place, and I would use it if you where paying my bills but I would always put up an argument against.

[oddz]

An application lacking abstraction between database rows and application level entities is one which is tightly coupled to the specific storage mechanism. Tight coupling at any level will result in a system more difficult to maintain and change over time. Not to mention repeating the same query logic over and over is not DRY.

Simple example:

$user = user::load(1);

Is much more concise and adaptable to changes in implementation than:

SELECT * from users;

scattered about everywhere.

Taking the example further a single entry find method that allows pagination, sorting, and filtering in the application language like so:

Blog:: find(array(‘title_has’=>‘plane’,‘limit’=>10));

Is much more adaptable to change than scatterring a bunch of different variations of selecting against the blog table everywhere.

SELECT * FROM blogs WHERE title LIKE ‘%plane%’ LIMIT 10

I see it constantly from newcomers here who try to create a function to encapsulate some type of select logic. However, they always post code that is limited in its capacity for reuse requiring repetition of similar logic in another function and another function and another function. Where as if an ORM or AR was used there is typically a single method to filtering, sorting, etc that doesn’t require repeating similar code everywhere.

Furthermore, so long as the API is used the storage mechanism can typically be switched with ease. When SQL queries are hard-coded that isn’t possible without rewriting the entire application. The same can be said for adding caching layers. When the application is built in a way that it is loosley coupled to the persistent storage mechanism the domain level entities can be cached completely alleviating trips to the db in some cases.

When building an application there should ALWAYS be an abstraction between the rows in the db and application level entities. it doesn’t necessarily have to be a open source ORM or ActiveRecord but it should be something more than the same SQL queries scattered about every where. ORMs and ActiveRecord merely facilitate that process and open source providers facilitate it in a way that means you don’t have to write your own and built something completely custom that the next person inline will probably hate for having to maintain.

[s_molinari]

It’s funny and so coincidental, or maybe not, since I am working hard at learning, but I am reading a book called “Implementing Domain Driven Design” by Vaughn Vernon and in it he writes about an “Anemic Domain Model” which is actually a term coined by Martin Fowler.

Basically, as I see it, an anemic domain model is one that doesn’t actually model the domain. Often this happens, because developers try and think more in terms of the database normalization and relations and less in terms of their true domain model. They wrap the application (albeit internally) more around the persistence than around the goals of the application. An ORM helps the developer think more in terms of the domain model and the goals of the application and less in terms of database relations and normalization. I think that is what I was trying to say.

I might still be wrong though.

Scott