|
You should watch the video. I have always been against most use of patterns and abstraction, so I like what I hear. You may not agree, I don't know.
|
|
|
|
|
Sorry, no time right now. The boss wants me to do some work.
I have nothing against having layers. Separation of concerns (as way as strengthening the single responsibility principle) in each layer has proven to be very helpful to keep things tidy.
In the past I have seen bad examples of overdesign (using every pattern known to man at least twice and adding every available framework for and against everything) or total anarchy (the usual spaghetti mess).
I don't know which of the two I dislike more. Why can so many people not go the straightest way towards their goal?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Now imagine a 2013Helper, a 2014Helper and a 2015Helper class.
Static classes ofcourse, no inheritance
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
I read his blog from time to time. I see he has been a member for over 10 years with little activity though.
|
|
|
|
|
The man is busy...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I'm busy working on a WPF MVVM project now where the developer liked to use patterns, lots of abstraction and base classes etc. A few too many layers in some cases. Like an onion that makes you want to cry.
|
|
|
|
|
Summarize the video...
What's wrong with repositories?
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: What's wrong with repositories?
You don't really need them. They really serve no purpose unless you want to complicate your application at some level. There are engineers who love to abstract upon abstract, and then there are those of us, who don't.
I have been to both worlds, and have worked in both worlds, and care for the world with "less" abstraction.
Watch the video when you get a chance. I already summarized the video in my original post.
|
|
|
|
|
Sounds like you're confusing 'repositories' with 'factories'... When I hear repository, I think Data Access.
If it's not broken, fix it until it is
|
|
|
|
|
Entity Framework implements the repository pattern behind the scenes, and DbContext is its UoW. So why are you writing another layer of abstraction on top of it? BTW, I was talking about repositories and not facades.
You can always add a simple layer on top of Entity Framework, if needed.
|
|
|
|
|
Emilio Largo wrote: You can always add a simple layer on top of Entity Framework, if needed.
Yes, stick in your DAL.
|
|
|
|
|
I agree. Repository definition: a place, building, or receptacle where things are or may be stored.
|
|
|
|
|
I believe the best way to do it is the way you are most comfortable doing!
New version: WinHeist Version 2.1.1 new web site.
I know the voices in my head are not real but damn they come up with some good ideas!
|
|
|
|
|
We got a "weird and wonderfull" section devoted to that idea
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I ought to go there more often as I'm both "weird and wonderful"?
New version: WinHeist Version 2.1.1 new web site.
I know the voices in my head are not real but damn they come up with some good ideas!
|
|
|
|
|
Mike Hankey wrote: I ought to go there more often as I'm both "weird and wonderful".. and humble
FTFY
If it's not broken, fix it until it is
|
|
|
|
|
|
He didn't really have a concise or proper conclusion, I agree.
My take away was to keep your solutions simple (maintainable) and one key way to doing that is by implementing less abstraction, starting with this Repository Elephant-sh*t.
|
|
|
|
|
Yeah, and I agree with that, but it shouldn't take an hour and a half to say that.
Emilio Largo wrote: this Repository Elephant-sh*t.
And now I have to laugh at these "Hortonworks" ads I see on the CP home page. Are they purveyers of that shtuff?
|
|
|
|
|
I lost interest after watching for a while. He sounds like a pretentious twat, but that's probably my just bias against long-winded people (and I feel pissed off in general today. Don't mind me...)
I bet he could have made his point in 15 minutes, but that would probably make him unconvincing in the eyes of PHB-type individuals. KISS could also mean Keep It Short & Sweet, you know.
|
|
|
|
|
Agree! People are dumb and try to hide low qualification behind pattern names. Real programmers invent pattern from the head! And not only pattern, but ANY algorithm! Patterns exist just for IT monkeys.
|
|
|
|
|
And how many of these "real programmers" do you propose to employ? How much will they cost? Can every organization make a living this way?
What you say is the opposite extreme, there is no need to reinvent the wheel. Patterns are most useful when applied properly, and not just in software development. People have been using them for millennia in all sorts of industry.
|
|
|
|
|
I was investigating whether or not I wanted to use a repository pattern and stumbled across this video. He makes an interesting point about avoiding unnecessary abstractions, but after some thought I realized that the repository pattern isn't necessarily a bad thing. For example, it would allow me to develop entirely against an RDBMS, but at some point migrate some of my data storage to an alternate (e.g no-SQL) without - in theory - having to pull my application to pieces.
I also found it disingenuous to suggest avoiding libraries and abstractions then go on to use LINQ-SQL as an example of keeping things simple. I guess it is simpler in your application, but he should have recognized it for what it is.
There is also the potential for deviating from standards (e.g. logging and exception handling) if left to invidivual developers. It could be beneficial to collect all interactions with a data store in a repository so standards can be maintained consistently in one place.
In all in all, it is one person's opinion of better design and we all have one of our own that is better
|
|
|
|
|
Keep your friends clothes and your enemies closets.
|
|
|
|