PHP applications without ORM's - sharing expierience

Yes, I remember Maphper because you did the shameless plug some time ago :slight_smile: Yes, I agree, this is a clever way of avoiding the issue of related entities with some magic.

While Maphper is a nice example of a simple and clever ORM it still would require me as a programmer to live in two separate paradigms for the simple reason that the ORM will take care of all basic and simple needs but for more complex operations I will still have to fall back to raw sql - either bypassing the ORM entirely of by extending it with my custom methods that will pull and write data using specialized sql queries. To me it appears simpler to just choose one paradigm and not have to learn to use the other nor mix them together.

In the article you posted I found two quotes that apply to me:

Show me your flowcharts and conceal your tables, and I
shall continue to be mystified. Show me your tables, and I won’t usually
need your flowcharts; they’ll be obvious.

[…]

Show me your code and conceal your data structures, and I
shall continue to be mystified. Show me your data structures, and I
won’t usually need your code; it’ll be obvious.

I other words, I learn most about how a system works by looking at the database structure, which provides a much clearer view than application objects. And databases are standardized so there is no need for a programmer to learn how my application is structured and how the objects are interconnected. Sure, you can maintain graphic object models as part of the documentation but it’s a bit more hassle.

I understand this may be subjective and to some people being data store agnostic may work well but to me the database structure is what describes application stuff most clearly and immediately, especially when the database tables and fields have useful comments acting as a documentation.

[quote=“TomB, post:20, topic:238732”]
Whether or not to create concrete classes for entities or not is an interesting discussion, personally I am against it[/quote]
I am also not fond of this but then what benefits do you gain by pulling data into stdClass objects? Certainly, it gives some power for Maphper to do some magic and inject related objects, for example. But other than that they are like plain arrays. To me most benefit from using objects as data structures (if I were to use them) is having IDE autocomplete, all the class signatures that act as a documentation and argument hinting. If we don’t use concrete classes for entities then we are essentially dealing with dummy objects that are almost identical to arrays.

I tend to agree with you because I remember a while back when I used classes for data stores I also put behaviour into those classes. That’s why I asked @ahundiak earlier what kind of behaviour he thinks is suitable in an entity class. When I put behaviour into the classes then the methods were tightly coupled to the concrete class. This became problematic when I wanted to use the same behaviour in other places - then I could either just duplicate it (not nice) or refactor it out but I couldn’t just move the methods outside without modification so it was always some kind of additional work. So now I’m wondering why put even simplest behaviour into data structures if it appears cleaner for them to be manipulated by independent classes because then the classes can be reused in multiple places regardless of how the data is stored.

Thanks for the link, it’s a long and an interesting article indeed! His claim that OOP is a failure is a bit far fetched maybe but he has interesting arguments to prove his point. I don’t know if I can agree with him or not because I don’t have enough experience in good functional programming and those other languages to be able to make comparison. My programming self-education began with spaghetti functional programming, then moved to spaghetti OO programming and now is gradually moving towards more and more structured OO programming.

But I can see partial similarities in my and his thinking that programming shouldn’t be made too complicated than it needs to be so that’s why I’m currently trying to simplify how I build applications and get rid of abstractions that will require more maintenance than provide benefit. That’s why I’m now experimenting with not using an ORM at all and not worry about how to work around it in cases where the ORM will (certainly) fall short.

And I also agree with the article on data structures - seems sensible and reasonable.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.