3 ms·
You're going to seriously try serialize active records? Are you going to ship them to your clients as well to deseiralize? coupled with all their server data lo
by mythz 10y ago
You're going to seriously try serialize active records? Are you going to ship them to your clients as well to deseiralize? coupled with all their server data logic implementations? Active Records aren't DTO's and this doesn't work in the real-world, you can of course try to force it, but then you'll just be fighting fires trying to workaround new runtime serialization and implementation coupling problems.
> Of course it's not clear to you how everything else works when we've only seen a single select example
It's not clear because it's hidden behind your active record wrapper so the call-site doesn't know anything about it or provide any way they can change it.
> None of those things are clear in yours either from the select example shown here.
It's absolutely clear since `db` is just the open ADO.NET DB Connection which the query is obviously using. Users don't need to know anything more about the Micro ORM to use transactions as it just works naturally with ADO.NET DB Transactions.
> Yes there is, preference of the ORM writers, nothing more.
It's the preference of devs with experience writing ORM's as to what provides the optimal, intuitive API with the least friction, max productivity and reuse. You can of course stick to creating a new ORM based on a custom Active Record pattern which you'll end up maintaining forever and no-one else will have experience using or want to use. So any of your code-bases using it will be stuck using a bespoke legacy DAL that will be unmaintained the second you stop maintaining it and move on to NIH'ing something else.
> Active records are practical, they're why Ruby on Rails got so huge so fast. Ignore this pattern at your own peril.
They're ignored in .NET because they provide no added value over what's already available, there's no peril to be avoided, they're worse in every way and have zero chance of returning with any meaningful impact in .NET.
- gnaritas 10y agoYou've succeeded in convincing me you that you have limited experience and an inability to see that the real world is much messier than your ideals. Do please stop trying to speak for .Net as if you represent the entire community, you don't, and you're just embarrassing yourself. In the real world, the corporate world, you'll find tons and tons of custom active record implementations because they always provide something external mapping libraries don't, context aware simplicity. So go pick up a Martin Fowler book on patterns and read what someone who actually knows what they're talking about says about it since you seem to think you've got it all figured out, it's obviously pointless trying to have a discussion with you.
- mythz 10y agoLOL, then you're as clueless as evaluating people as you are evaluating technology. If you think mechanically forcing the creation of unnecessary non-reusable classes eschews simplicity you have no idea about that either no matter how many pattern books you want to try hide behind - BTW if you had any clue about Martin Fowler you'd know he'd never reuse Active Records as DTO's (pretty embarrassing given you've started quoting him - go read up on his published DTO, Facade and Gateway patterns). But you're right there's no point in a discussion, you're stuck in your legacy ways (a .NET 1.0 API for your ideal theoretical .NET AR DAL really?) and can't see the approaches .NET has rightfully moved to - there's a reason you'd need to NIH your own DAL to get "your ideal API" you want (hint: it's not because it's an undiscovered ingenuity) - have fun NIH'ing your own tech debt!