Programmer Humor

Business logic would be transformations to the data. Like for a spreadsheet, the data layer would handle the reading/writing of files as well as the storage of each cell's content. The business logic layer would handle evaluating each of the formulas in the cells, and the presentation layer draws it on the screen.

I think the part where it gets confusing is that each of these layers are pretty tightly coupled. The end destination of the presentation layer might change, one might show it on a GUI, another might print it, and another might convert it to pdf or html, but each of those presentation layers needs to understand the data that it is presenting, so it's tightly coupled to the data layer. Same with the businesses logic layer, though it's tightly coupled on both the input and output sides. The design of the data layer constrains the possibilities of the other two, so it's hard to draw a clear boundary between the layers because they all need to know how to walk the same data.

My mental flow chart for this is more of a data layer in the middle instead of business logic, where business logic is to the side with arrows going both ways between it and data layer, then the presentation layer also accessing the data layer directly, which I suppose is a different permutation of what you described.

Though another way to look at it does make sense. For a website, think of the database as the data layer, the server scripts as the business logic layer, and the client side scripts/html/css as the presentation layer. That one also follows the layered approach where the presentation layer is talking with the business logic layer.

Exactly, have fun trying to get test coverage without dependency injection

COPILOTS, COPILOTS, COPILOTS, COPILOTS!!!!

There, I updated it for you and I hate it.

you missed the best part

AAAAHHHHRRRRGGGHHHHHHHAAAAAAAA! sweat pouring off balmer as his body goes into shock from the pain

Obviously don't have the full context, but rarely is it ever advisable to give third parties direct access to a database. There are many reasons for this, like, for example, the fact that doing so makes schema migrations practically impossible.

That's why you build the api first. If you need to "cut through" anything you build an api for that instead.

That's just bad interface... When you design an API as if operations were independent, but they aren’t, you run into these issues.

Don't add "cut through the lawyers" functions, fix your interface.

A complex bottom may have difficulty mating with a simple top

Yeah, Java's enforcement of everything must be a class put me off of the language right from the start. I was already used to C++ at that point and hated that I couldn't just write a quick little test function to check something, it needed a bunch of boilerplate to even get started.

I still think C++ has a great balance between object oriented and sequential programming. Not sure if it's the best, but I can't think of ways to improve on it, other than built in concurrency object stuff (like monitor classes that have built in locks that prevent more than one thread from accessing any of its functions at the same time, basically guaranteeing any code in it has mutual exclusion).

All absolute statements are false.

they really made their domain pee rate dot france huh

At least one of them is a pedophile, so you're probably not wrong

If you haven't seen the vid it's 500 levels of awkward cringe that's hard to watch. Had to do with one of the MS version releases. They're acting so awkward you can't tell if they're yakked out in coke or just that socially awkward. Full disclosure I'd be worse than them in that situation, just calling it like it is.