Yeah, sometimes a kludge is the best way to go. But that’s usually because of external pressures (hello deadlines).
But, yes, separation of concerns is one of the pillars of programming. Most apps - even web apps - are layered. The most prevalent web app pattern is MVC - Model, View, Controller.
The Model is, essentially, your data - encapsulated by objects - that interact with each other. Sometimes Models are simple (forum posts). Other times, they’re complicated (a graph of objects that act on one another, like one’s financial portfolio).
The View is exactly what it sounds like. It’s what the end user sees. It’s how they interact with the Model.
The Controller is the glue that holds it together. It handles user input, and passes it to the Model. It returns the proper View based on what the user requests, or based on changes in the Model.
Now, MVC isn’t the only pattern. Benny, because he’s using ASP.NET Web Forms, is using a different pattern. But the idea is the same - layered components.
Why is this beneficial? Because it allows the developer to change/edit/maintain part of the system without worrying about messing up something else. If I decide to create a new site layout, I don’t need to worry about my database code, or my Controller(s). I simply make new templates and CSS.
This approach even works in single page apps. Inline JavaScript and CSS is an example of a code smell. It’s a sign of doing it wrong. Most JavaScript comes in the form of externally referenced libraries, with page-specific code placed within script tags either at the top of the HTML document (with some form of code that waits for the entire document to load into the browser’s memory because JavaScript is greedy/fast and will attempt to access the DOM before it’s available) or the bottom. Similarly, external CSS is loaded in order, so simply start with your sitewide rules, and add page-specific files as necessary.
And, of course, separation of concerns isn’t a web-only paradigm. It’s how programming is done, period. Concrete, and layered, components that communicate with each other through clearly defined interfaces. Which, since you mentioned it in passing before, is leveraged/aided by things like polymorphism.
But, yes, separation of concerns is one of the pillars of programming. Most apps - even web apps - are layered. The most prevalent web app pattern is MVC - Model, View, Controller.
The Model is, essentially, your data - encapsulated by objects - that interact with each other. Sometimes Models are simple (forum posts). Other times, they’re complicated (a graph of objects that act on one another, like one’s financial portfolio).
The View is exactly what it sounds like. It’s what the end user sees. It’s how they interact with the Model.
The Controller is the glue that holds it together. It handles user input, and passes it to the Model. It returns the proper View based on what the user requests, or based on changes in the Model.
Now, MVC isn’t the only pattern. Benny, because he’s using ASP.NET Web Forms, is using a different pattern. But the idea is the same - layered components.
Why is this beneficial? Because it allows the developer to change/edit/maintain part of the system without worrying about messing up something else. If I decide to create a new site layout, I don’t need to worry about my database code, or my Controller(s). I simply make new templates and CSS.
This approach even works in single page apps. Inline JavaScript and CSS is an example of a code smell. It’s a sign of doing it wrong. Most JavaScript comes in the form of externally referenced libraries, with page-specific code placed within script tags either at the top of the HTML document (with some form of code that waits for the entire document to load into the browser’s memory because JavaScript is greedy/fast and will attempt to access the DOM before it’s available) or the bottom. Similarly, external CSS is loaded in order, so simply start with your sitewide rules, and add page-specific files as necessary.
And, of course, separation of concerns isn’t a web-only paradigm. It’s how programming is done, period. Concrete, and layered, components that communicate with each other through clearly defined interfaces. Which, since you mentioned it in passing before, is leveraged/aided by things like polymorphism.
