How to increase readability of an interface (C#)
-
@asdf said in How to increase readability of an interface (C#):
That, of course, is fucking moronic and has nothing to do with the repository pattern as it was intended.
patterns aren't applied as intended, they are always applied in the most stupid, moronic and damaging way.
I cringe when I read they want "design patterns" in a job ad because of that.
-
@fbmac said in How to increase readability of an interface (C#):
website - web service - facade - orm - database
So far, so good. Except from the "website calls web service" part.
@fbmac said in How to increase readability of an interface (C#):
some people just love to spend the day writing mapping code like:
obja.name = objb.name
obja.phone = objb.phoneI'll get my clue bat, those idiots need to be neutralized immediately!
Now here's an example of where YAGNI actually applies: Don't write an additional model class until the ORM-generated class actually changes in a breaking way. Because, spoiler alert: You can still manually write a class with the same name and the same interface as the old, generated class yourself if you need to maintain a stable API. I know, magic, right?
-
@asdf said in How to increase readability of an interface (C#):
So OOP is bullshit, then, in you opinion?
signs point to Yes
-
@flabdablet Oh God, another apostle of the functional programming religion. sigh
Not that I hate FP, I just hate the people who claim it solves all our problems and that the alternative is bullshit.
-
@anonymous234 said in How to increase readability of an interface (C#):
dozens of magical ALLCAPTERMS that were apparently some kind of meta-language made out of preprocessor macros
-
@flabdablet Macros used to be so cool that they featured in the name of the tool:
Microsoft Macro Assembler
-
@anonymous234 said in How to increase readability of an interface (C#):
Makes it visually very clear what's going on with only some minor changes
-
@asdf said in How to increase readability of an interface (C#):
Are you really trying to tell us that the facade pattern doesn't have any merit?
When it looks as similar to the stuff underneath as a PIN pad skimmer looks to a PIN pad: that's exactly what I'm trying to tell you.
-
@flabdablet I like this analogy
-
@flabdablet OK, good point. :D Yes, a facade whose methods don't contain actual logic and which doesn't actually reduce a complex API to a few methods doesn't make any sense.* In case of a repository, though, the facade usually actually contains logic and isn't nearly as complex as the underlying ORM.
*Unless you need it for technical reasons, e.g. because it defines the ABI of a library. But I guess I wouldn't call it a facade in this case.
-
@asdf said in How to increase readability of an interface (C#):
Basically, a repository is a facade for your data layer. Instead of accessing the global DB object / data mapper / ... everywhere in your code and perform the same 3 steps to get a user by email address (code duplication! tight coupling!) you now have a Users class with a method getByEmailAddress() which does all that for you
So... it's a data layer?
-
@asdf said in How to increase readability of an interface (C#):
The problem is that this may mean that you have to rewrite the whole application if you didn't think about abstractions/coupling at all during the initial software design. Just take NodeBB and <insert_person_whose_identity_I_can't_remember_here>'s efforts to port it to a relational DB as an example.
That problem is the opposite of YAGNI. They put the program on MongoDB without changing it to run on MongoDB, because Mongo could (inefficiently, and with bug-land-mines that'll go off eventually) handle the simple key/value system they'd come up with.
That's just laziness.
-
@asdf said in How to increase readability of an interface (C#):
Are you really trying to tell us that the facade pattern doesn't have any merit?
... but Entity Framework already created a
GetUserByEmailAddress()
method.I'm sure it's a useful pattern on its own, but we're talking about where it's being used to wrap another already-existing class basically 1:1.
-
@blakeyrat said in How to increase readability of an interface (C#):
... but Entity Framework already created a GetUserByEmailAddress() method.
Ah, so it creates repository classes with basic getters automatically? I have to admit that I've never used EF.
@blakeyrat said in How to increase readability of an interface (C#):
being used to wrap another already-existing class basically 1:1
Yeah, that's always dumb. (Unless you have a specific technical reason for that, see above.)
-
@asdf @asdf said in How to increase readability of an interface (C#):
Unless you have a specific technical reason for that, see above
It's my firm belief that people who think they do have a specific technical reason for that are fooling themselves.
(anybody else experiencing a bit of a cooties blizzard?)
-
@flabdablet said in How to increase readability of an interface (C#):
It's my firm belief that people who think they do have a specific technical reason for that are fooling themselves.
There is a valid reason I can think of: The wrapper defines the ABI (which must be kept stable) for a native library.
@flabdablet said in How to increase readability of an interface (C#):
(anybody else experiencing a bit of a cooties blizzard?)
Post have been streaming in with a huge delay for me for hours.
-
@asdf said in How to increase readability of an interface (C#):
Ah, so it creates repository classes with basic getters automatically?
More or less. One of the earlier examples that used EF directly looked like this:
private static void PrintAllInventory() { // Select all items from the Inventory table of AutoLot, // and print out the data using our custom ToString() // of the Car entity class. using (var context = new AutoLotEntities()) { foreach (Car c in context.Cars) { WriteLine(c); } } }
AutoLotEntities
is theDbContext
- essentially, the database model.context.Cars
is theInventory
table (aDbSet<Car>
), and aCar
is a row in that table. Some modifications were made for that example (e.g., "Inventory" was renamed to "Car" to demonstrate the model to database mapping attributes) but the important stuff was all autogenerated.
-
People often try to implement repository patterns on top of EF, and every time they do, I wish someone had been around to facepalm and explain to them that EF is a repository. It's already done.
But you can be sure CodeProject will tell you how to add eleventysix more layers on top, just to make it easier.
-
@Dreikin Okay, but that just looks like the standard stuff that every ORM does to me. How would you write more complicated queries involving JOINs, like the following (example from the SQLAlchemy docs)?
adalias1 = aliased(Address) adalias2 = aliased(Address) session.query(User.name, adalias1.email_address, adalias2.email_address).\ join(adalias1, User.addresses).join(adalias2, User.addresses).\ filter(adalias1.email_address=='jack@google.com').\ filter(adalias2.email_address=='j25@yahoo.com'):
-
@asdf in c# you usually add your own methods to generated code using "partial" files
-
@Magus if you want to use DI you are going to have to because EF is a steaming piece of shite.
I normally prototype in EF and rip it the fuck out and use dapper after wards. DI and a report pattern over the top is a good idea.
-
@lucas1 said in How to increase readability of an interface (C#):
@Magus if you want to use DI you are going to have to because EF is a steaming piece of shite.
I normally prototype in EF and rip it the fuck out and use dapper after wards. DI and a report pattern over the top is a good idea.
It's a good thing I would never want to use DI, because DI is bullshit
-
@lucas1 said in How to increase readability of an interface (C#):
@Magus if you want to use DI you are going to have to because EF is a steaming piece of shite.
I normally prototype in EF and rip it the fuck out and use dapper after wards. DI and a report pattern over the top is a good idea.@fbmac said in How to increase readability of an interface (C#):
It's a good thing I would never want to use DI, because DI is bullshit
Do neither of you know anything about DI?
-
@Magus I've read about dependency injection, yes. It works by moving the dependency from readable source files to unreadable XML files, or to an upper, less readable layer. And by making debugging more difficult.
-
@fbmac Ah, yeah, that makes sense. In that case, you just need to extend the existing repository class, and you're right: An additional repository class doesn't make much sense.
-
@fbmac said in How to increase readability of an interface (C#):
It works by moving the dependency from readable source files to unreadable XML files
And, again, you're assuming the concept is shit because a specific implementation you saw is shit.
That said, a DI framework is overkill for most applications.
-
@asdf said in How to increase readability of an interface (C#):
@Dreikin Okay, but that just looks like the standard stuff that every ORM does to me. How would you write more complicated queries involving JOINs, like the following (example from the SQLAlchemy docs)?
adalias1 = aliased(Address) adalias2 = aliased(Address) session.query(User.name, adalias1.email_address, adalias2.email_address).\ join(adalias1, User.addresses).join(adalias2, User.addresses).\ filter(adalias1.email_address=='jack@google.com').\ filter(adalias2.email_address=='j25@yahoo.com'):
Not sure for that example. If I gather right, it's doing a self-join on the addresses table to find a user with both of those email addresses? Probably what @fbmac said. However simple joins on keys are automatic, as in this example:
private static void PrintAllInventory() { // Select all items from the Inventory table of AutoLot, // and print out the data using our custom ToString() // of the Car entity class. using (var context = new AutoLotEntities()) { foreach (Car c in context.Cars.Include(c=>c.Orders)) { foreach (Order o in c.Orders) { WriteLine(o.OrderId); } } } }
c.Orders
pulls the related rows from theOrders
table.For more complex joins like your example, someone more familiar with EF and/or LINQ would have to tell you.
-
I really didn't see many implementations of DI. Maybe because most people know it's bullshit?
-
@Dreikin said in How to increase readability of an interface (C#):
However simple joins on keys are automatic
So it's probably comparable to SQLAlchemy, then.
-
@fbmac said in How to increase readability of an interface (C#):
I really didn't see many implementations of DI. Maybe because most people know it's bullshit?
DI becomes interesting if you need to build an extremely customizable framework, where users need to be able to override the default behaviors with custom code easily. (Example: E-commerce system. Every customer wants something different there.)
You can, of course, add millions of factories, plugin hooks and whatever to your code, which results in insanity both for you, the framework developer, and the person who has to implement the customizations. Or you can do the sane thing and use a DI framework. In that case, customization is as easy as telling the DI framework which parts of the code (interfaces) you want to override and just write custom classes which implement the correct interfaces.
-
@asdf you know very well that isn't what people are doing. all these "patterns" are being used in the most ridiculous, wrong, possible way
-
@fbmac A concept isn't bad just because people abuse it. Stop claiming that this is the case.
-
@fbmac No it isn't.
-
@asdf Calling "pattern" a concept that you should only very rarely use is bullshit. There wouldn't be frameworks for this shit if their use were restricted by the few cases were they make sense.
-
@lucas1 Yes, it is.
-
@fbmac said in How to increase readability of an interface (C#):
It works by moving the dependency from readable source files to unreadable XML files
If you do it horribly.
I'd make EF support DI by putting
[Export]
attributes on the classes, and just not worry about any of that.@asdf said in How to increase readability of an interface (C#):
@fbmac A concept isn't bad just because people abuse it. Stop claiming that this is the case.
Exactly this.
Seriously, the Java way of doing things is almost always horrible.
-
@Magus yes I do.
-
@fbmac nope, sorry incorrect. Don't be a blakeyrat.
-
@fbmac said in How to increase readability of an interface (C#):
There wouldn't be frameworks for this shit if their use were restricted by the few cases were they make sense.
People are very talented at making the trivial complicated. But it is trivial.
-
@lucas1 I disagree
-
When I see someone shout loudly "this is always shit, and can never be useful", I know they are normally either shit, inexperienced or ignorant.
-
@fbmac I'm starting to think I wouldn't like to have you as a co-worker. You seem like the kind of person who refuses to use certain techniques without even evaluating them first, just because they've heard they're bad and "enterprisey".
Calling "pattern" a concept that you should only very rarely use is bullshit.
The very definition of a pattern is a proven concept you should apply under very specific circumstances. This is not bullshit, this is the definition of a software pattern. If someone applies a pattern when its requirements aren't met, it's that person's fault for being stupid, not the pattern's.
@fbmac said in How to increase readability of an interface (C#):
There wouldn't be frameworks for this shit if their use were restricted by the few cases were they make sense.
TDEMS. There have to be frameworks for DI because it's a complex problem you have to solve, which you cannot easily solve with ad-hoc code. The whole point of DI is to keep your own code clean and let a pre-existing framework do the job of adding the necessary hooks to it.
-
@asdf said in How to increase readability of an interface (C#):
The very definition of a pattern is a proven concept
How is any of it proven? Proven to do what?
-
@fbmac https://www.youtube.com/watch?v=hnPPItvvNB0
Guy uses TDD with some DI stuff to mock stuff. Does it right in front of you.
-
@asdf said in How to increase readability of an interface (C#):
The very definition of a pattern is a proven concept you should apply under very specific circumstances. This is not bullshit, this is the definition of a software pattern.
The definition of a 'pattern' in software is 'some code you see a lot'. That is all. It isn't something you apply. Teaching that it is is what brings about the Cargo Cult.
-
@fbmac said in How to increase readability of an interface (C#):
How is any of it proven? Proven to do what?
Okay, I'm starting to feel like you've never heard a (decent) lecture on software engineering. Patterns are meant to be distilled best practices for very specific problems. If you solve a software design problem in a specific way many times, and that way proves to be useful/flexible/readable and sustainable (i.e. the code still looks reasonable after a few refactorings), then you've found a pattern.
-
@asdf said in How to increase readability of an interface (C#):
@Dreikin said in How to increase readability of an interface (C#):
However simple joins on keys are automatic
So it's probably comparable to SQLAlchemy, then.
Probably. After some cursory research, it looks like what that example can be implemented via LINQ. Something like (I don't guarantee this works as-is):
var result = from a in context.addresses join b in context.addresses on a.userId equals b.userId where a.email == "jack@google.com" where b.email == "j25@yahoo.com" select new { userId = a.userId, email1 = a.email, email2 = b.email }
Although as you can see at the link, much more complex ones are possible, and this may not be the best way to implement that example.
-
@Magus said in How to increase readability of an interface (C#):
It isn't something you apply.
Yes, it is. Definition from Wikipedia:
In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
@Magus said in How to increase readability of an interface (C#):
Teaching that it is is what brings about the Cargo Cult.
Yes and no. No, because most of the time, patterns are misused because they're applied incorrectly (i.e. the situation is not the one the pattern should be used for). But also yes, because people need to be told that patterns should only be applied if you have an actual design problem that could be solved by one, not just for the sake of it.
-
@asdf said in How to increase readability of an interface (C#):
Patterns are meant to be distilled best practices for very specific problems.
You distill software, like wine?
-
@fbmac said in How to increase readability of an interface (C#):
You distill software, like wine?
Why not? I like the smoky taste of burned money.