Timeline for How to organize database access logic for the infrastructure and application layer when avoiding ORM tools?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 26, 2020 at 19:15 | comment | added | Robert Harvey | Yep. As I said, I'm an old database guy, where normal forms still rule the day. For what it's worth, you can still have first-class objects in your business model. Nothing prevents you from doing that, including ORM's and DTO's. That's the whole reason we have layers of indirection in the first place: to provide the necessary isolation between pure data repositories (which know nothing about our business logic) and domain classes (which shouldn't know anything about the way they are persisted). | |
| May 26, 2020 at 18:23 | comment | added | Robert Bräutigam | I'm not talking about data at all. When I say select the customer instead of its data, I mean exactly what I say. The resulting object will not ever surrender its data to outside objects. You can't ask for a name or address or whatever. You can ask it to freeze all credit cards, or login or whatever is needed in the context. Objects are not data holders, that's the point, those would be database records. A model is not a database. The domain is not a data model. There are no normal forms, "data" may be as redundant as needed, it doesn't matter. | |
| May 26, 2020 at 18:15 | comment | added | Robert Harvey | But then, I'm an old database guy. The fashion nowadays seems to be storing classes as key/value pairs in large document databases. If you do that, you don't need fourth normal form. But good luck running a report or doing statistical analysis. | |
| May 26, 2020 at 18:13 | comment | added | Robert Harvey | What you're probably thinking about is an "aggregate," in the DDD vernacular. If I want to retrieve a customer's name, that is easily done within the class. The moment that I need some meaningful behavior, that class fails. If I need to know where the customer lives so I can send him something, that is an Address object. If I need to know his account balance, that involves several tables. There's no getting around fourth normal form. | |
| May 26, 2020 at 18:10 | comment | added | Robert Bräutigam | Would I expect a dollar to transfer itself or a bolt to assemble itself? Sure, maybe. Depends on the requirements. In object-orientation anthropomorphization rules the day. SRP doesn't (well, shouldn't), in fact it's pretty down the list, if even that, depending on which interpretation you subscribe to. | |
| May 26, 2020 at 18:03 | comment | added | Robert Bräutigam | Thanks for taking the time to comment in depth! Business applications move data only if you choose to think about it that way. I've written even a messaging system on top of Kafka, that literally move data without actually having even one record type, or having even a single getter. If you execute an SQL statement, or get data through messaging, that data does not have to go somewhere. It can in fact become a part of a "real" object that has behavior. You don't select data for a customer, you select the customer. | |
| May 26, 2020 at 14:09 | comment | added | Robert Harvey | And if all you're saying is "Let your Customer class be a Customer class," I'm actually all for that. But my experience is that business software doesn't really work that way. Treating that customer as purely a data point is unavoidable, even if it's only because we have to translate them to a JSON object to get them over the wire. | |
| May 26, 2020 at 14:08 | comment | added | Robert Harvey | Business applications are like that. They're like assembly lines. They move data from one place to another, and operate on that data. In the "old days," these applications used to be complex, monolithic monstrosities. Nowadays, our code actually does less, and we've learned to make our classes simpler and easier to maintain. The Single Responsibility Principle rules the day. | |
| May 26, 2020 at 14:04 | comment | added | Robert Harvey | Classes are Code + Data. I'm all for that fusion, where it is useful. Think of it this way: if you had a class that represented a bolt on an assembly line, you rightly wouldn't expect that bolt to know how to assemble itself onto a car, would you? If you had a dollar in a wallet, you wouldn't expect that dollar to know how to transfer itself into your checking account using double-ledger accounting, would you? | |
| May 26, 2020 at 14:00 | comment | added | Robert Harvey | When I read data from a database, I write a SQL statement. That data has to go somewhere. Where I now work, it used to go into a loosely-typed collection. Now it goes into DTOs using an ORM, your so-called Anemic Model. The ORM saves a ton of work, and the classes are code-generated anyway. | |
| May 26, 2020 at 13:46 | comment | added | Robert Harvey | OK, so I read your article, and the example you provide is that of a Point class, in fact the very same Point class that I use in my introductory programming classes. Deeply-nested inheritance hierarchies are common in graphical user interfaces, and while they are great at modeling UI, they're bad at almost everything else. | |
| May 26, 2020 at 10:42 | comment | added | Robert Bräutigam | The rationale is that the object-oriented style is much more maintainable. There are so many arguments to be made, for OO and against the procedural style above, that I've been writing about it for years, haven't even covered all the basics yet. | |
| May 25, 2020 at 21:07 | comment | added | Robert Harvey | I'm all for ideas that challenge the status quo, but some justifications are still worthwhile. Ideas without some rationale to back them up are not very useful. | |
| May 25, 2020 at 20:46 | history | answered | Robert Bräutigam | CC BY-SA 4.0 |