The Blakeyrat Coding Method
-
Ignoring all coding concepts that can be reduced to a TLA (Three Letter Acronym.)
IoC, crap. AOP? Worthless. MVC? Useless.
JUST. WRITE. CODE.
Discuss.
-
So, what you're proposing is moving to JWC?
-
OOP?
-
All of software engineering is bullshit and cargo cult beliefs.
Discuss.
-
-
Do you deny DRY, too? At least KISS gets a pass...
TBH (hehe), there is a lot of cruft like this in the programming world, but once in a while they come up with something usable. MVC, for example, results in quite nice and tidy code once you wrap your head around it.
-
Yes, NAMES ARE BAD!
NAB.
-
OOP?
NOT ALLOWED.
Do you deny DRY, too? At least KISS gets a pass...
I've never heard the term "DRY" before in my life.
KISS gets a pass, as does (say) ACID for databases. THIS IS ON PURPOSE. BLAKEYRAT FULLY THINKS THROUGH HIS PROPOSALS 100% ALWAYS.
MVC, for example, results in quite nice and tidy code once you wrap your head around it.
I've not yet touched a project where MVC made sense. We usually ended-up making controllers without models, like, all over the place because the "model" depended on what the client requested and had no set definition.
-
-
MVC, for example, results in quite nice and tidy code once you wrap your head around it.
No pass, 3 letters. MVVM is fine though, I guess.
-
Ahh, of course. BCM!
-
-
What about the most important coding methodology, WTF?
-
Nope, Dunning-Kruger.
-
Ahh, of course. BCM!
I've never heard BCM before in my life and also Google has nothing on it.
-
But... you just invented it!
-
I thought you abbreviate it as tBCM
-
Retain CYA.
-
I've never heard the term "DRY" before in my life.
Huh. How's living under a rock going for ya? I think I've heard it numerous times on this very forum...
We usually ended-up making controllers without models, like, all over the place because the "model" depended on what the client requested and had no set definition.
I believe your whole application depends on what the client requested...
Anyway, I don't know what definitions you follow, but what would you ever consider to be a "model"? Don't you have any sort of data layer? Doesn't need to be an ORM which you hate, just some sort of sproc/SELECT wrapper.
-
Anyway, I don't know what definitions you follow, but what would you ever consider to be a "model"? Don't you have any sort of data layer?
It's usually reporting data for charting purposes, where the schema of the data depends on stuff like, "which metrics did the user select? Did the user select grouping by a date, or grouping by a metric value, or no grouping?" etc. We could either write 57,324,323 models to support every variation, or just skip the model and do the work in the controller.
Sure I bet if you have a super-simple application that does nothing but fetch data from a database and present it unaltered MVC works great. I've never worked on an application like that.
-
I've never heard the term "DRY" before in my life.
###Don't Repeat Yourself.
Factor your code so that each concept or constant is expressed only once. If you need to make a change to the code later, you only need to change it in one place.
-
Sure I bet if you have a super-simple application that does nothing but fetch data from a database and present it unaltered MVC works great. I've never worked on an application like that.
I agree with this. A model layer is one layer too many. Why write imperative code when you can write functional sql code, directly and more clearly? (SQL is a functional language, after all...)
This observation is specifically why I ditched primarily imperative languages with poor functional support, in favor of functional languages with good imperative support. About half of what a program does is query data structures.
-
Does it still count as MVC if your model is in SQL, your controller is in a server-side language, and your view is client-side javascript?
-
Sure I bet if you have a super-simple application that does nothing but fetch data from a database and present it unaltered MVC works great.
Okay wait, isn't that kinda what you do? As in, your controller gets the request, directly tells the database "give me metrics A, B and C, grouped by year", and presents the data it got to the user?
In my book, it's still kind of MVC, with the database and ADO provider working as a model. Ugly as sin, but workable.
-
I think the buzzword for that is MVVM, and it makes a lot of sense.
-
A lot of the talk about MVC MVVM or whatever seems like people are more focused on proper classification that understanding why or just getting stuff done.
-
A lot of the talk about MVC MVVM or whatever seems like people are more focused on proper classification that understanding why or just getting stuff done.
Somewhat, yeah. MVC is a bit simpler than MVVM in that regard - model hands out the data, controller decides which data to get from the model, and the view... well, the view is just the view.
MVVM, or at least the WPF flavor of it, is awkward as fuck on the VM layer (it's sort-of-a-data-object, sort-of-a-logic-container), and it's hard to figure out what goes there.
-
I like GFDOS as a term.
-
I would think the why is pretty simple. Splitting the "view" into a "view" and a "view model" lets you write front-ends declaratively, by issuing queries to the underlying view model, which is usually machine generated.
-
Somewhat, yeah. MVC is a bit simpler than MVVM in that regar
SHUTUPSHUTUPSHUTUPSHUTUP
-
BBOM, anyone?
-
I would think the why is pretty simple. Splitting the "view" into a "view" and a "view model" lets you write front-ends declaratively, by issuing queries to the underlying view model, which is usually machine generated.
That sounds like literally nothing I've ever worked with. It sounds like you're having fun, though, so that's good.
-
I've never heard the term "DRY" before in my life.
Never read The Pragmatic Programmer?
-
Somewhat, yeah. MVC is a bit simpler than MVVM in that regard - model hands out the data, controller decides which data to get from the model, and the view... well, the view is just the view.
The controller can also determine which view to use. In the primary web-app that I maintain, that is very useful since we have about two dozen different controllers which each have 4 to 6 views. The underlying data and logic for each related view is 99% identical, but the views are significantly different. I think this is the use case that MVC was really intended for.
-
Sir, may I interest you in MVP?
-
That sounds like literally nothing I've ever worked with.
That could be. Every Haskell "data" type can be turned into a JSON value by making it an instance of "ToJSON", automagically. So I don't have to write viewmodels. I just have controllers return a JSON value that the MVVM model knows how to parse and bind to the view. Effectively, it eliminates having to explicitly deal with "transport" in the view layer. No ad hoc ajax requests are required.
-
-
ANJI - Add a Noodle and Jam It.
-
http://knockoutjs.com/
Oh, the "put an MVC framework into a view layer of your MVC framework" thingy.
Filed under: it's mvc frameworks all the way down
-
Sir, may I interest you in MVP?
I'm sure it has it's place, but I don't have a use for it. When I inherited the program I mentioned previously it was theoretically architected in MVP. The previous programmers did a shitty job and there was unnecessary code duplication everywhere. I got the architecture cleaned up so that the program was actually following MVP structures. However, due to the issues with similar-but-distinct-views I mentioned before, there was still a lot of code duplication (I probably could have cleaned it up more, but it was a big project already). I did some research and convinced my boss that the project really needed to be converted to MVC. Now that that's done, code duplication is (as far as I can tell) at a minimum.
Now to get the damn thing upgraded to .NET 4.5.
-
MVS
<granted no one calls it that.
-
Yes, that's obviously all the value it adds. Getting rid of ad hoc AJAX queries doesn't make anything simpler. Especially view layer code.
-
It's usually reporting data for charting purposes, where the schema of the data depends on stuff like, "which metrics did the user select? Did the user select grouping by a date, or grouping by a metric value, or no grouping?" etc. We could either write 57,324,323 models to support every variation, or just skip the model and do the work in the controller.
Sounds like how we present data, which is OLAP. It means you don't just have a model (of the base dataset) but also a metamodel (of how the end user can query it). MMMVC?
-
Sounds like how we present data, which is OLAP.
On one of the systems, it was OLAP. On another I worked on, it was a MongoDB query builder.
It means you don't just have a model (of the base dataset) but also a metamodel (of how the end user can query it). MMMVC?
It just means MVC is useless trash, as I've been saying.
-
I think the trick is to know a decent amount about all of theTLA buzzwords, so you can work out what's actually useful in them and use that while ignoring all the other bullshit
-
Right; like when I learned that IoC meant and realized I'd already been doing that for years.
-
I was told to use dependency injection for a project. Read around a bit and couldn't find a concise explanation until I found a Pluralsight video that made me wonder why you'd do anything else
The basic idea of DI, that is. Not specific DI frameworks
-
Do you deny DRY, too? At least KISS gets a pass...
BTW DRY is a fucking terrible acronym because it can easily be interpreted as the exact opposite of what you mean. Don't Repeat Yourself and Do Repeat Yourself are the same three letters, in other words.
-
Don't Repeat Yourself and Do Repeat Yourself are the same three letters, in other words.
But "Do Repeat Yourself" could be just as well expressed as "Repeat Yourself".
(Or maybe "Repeat Yourself Everytime"—RYE!)
-