If someone spent their time learning their tools, they will make better choices when writing the code without any additional time cost.
There are two variants of very similar code. Both do the same thing, both are readable and maintainable. The difference is not primarily in performance, it's in quality of craft.
Anything you say or do will be used against you by any future government. What's legal now, might not be legal tomorrow, and you will be jugged by your AI "friend". Welcome to dystopia.
This is more of a preference for bridge to be visible in application. Also the bridge may seem simple at first, but it also may gain associated data, like created_at, order, etc.
Yes, I would not put it just anywhere. But I have few rules about ORMs:
- Proper DB design first. You should be able to remove the ORM and DB should still function as intended. This means application-side cascade operations or application-side inheritance is banned.
- No entities with magical collections pointing to each other. In other words, no n to n relations handled by ORM layer. Create in-between table, for gods sake. Otherwise it becomes incredibly confusing and barely maintainable.
- Prefer fetching data in a way that does not populate collections. In other words, fetch the most fine-grained entity and join related data. Best if you craft special record entities to fetch data into (easy with EF or Doctrine).
- Most ORMs allow you to inspect what kind of queries you create. Use it as query building tool. Inspect queries often, don't do insane join chains and other silly stuff.
I would use ORM in one kind of app: where I would work with data that shares records that might need to be either inserted or updated, and there is several nesting levels of this kind of fun. You know, you need to either insert or update entity, if it exists, you should update, and then assign related entities to it, if it does not, then you should insert, and assign related entities to the newly created id. The ORM can easily deal with that, and on top of that it can do efficient batched queries, which would be really annoying and error-prone to hand-craft.
If the app does not require this kind of database with these kind of relations, I would not use ORM.
Pardon me for the tangent (just a general comment not directed to OP).
What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects!
struct Node<'a, 'b, 'c> {
data1: &'a Data
data2: &'b Data
data3: &'c Data
}
Wow. It's like teaching C++ and starting from SFINAE. Or C# and starting from type parameter constraints.
Please think of a real-world examples when teaching stuff. I am very eager to see the program a beginner would need to write that requires: 1) references in a struct; 2) 3 separate lifetime parameters for the same struct.
Yes of course. You have to demonstrate that you are very skilled at building with the particular bricks they use. Don't mention anything else to show your commitment to particular brick usage.
Right, imagine a company where the team decides to use Macromedia Flash for game UI only because they need to deliver something working on the next sprint. And then everyone gets stuck with that decision for more than a decade.
Say, you use the same foundation for both the game and tool. Nothing prevents you from building features on top that are optimized either for a tool or for a game! Plus you dogfood the system all the time.
Bytes aren't bricks.
Reshuffling them from scratch after a smallest change is cheap and fast.
Taking advantage of that is not stupid.
Proper communication and work with client is a skill, and architects have to deal with stupid requests too!
If's fun little article, but is a bit short-sighted. Probably because otherwise it would not work.