I suppose most of the developers have an idea of multi-layer architecture. We have DAL (Data access layer), we have BLL (business logic layer) and somewhere near the end of the road we have our UI. If you have a project which somehow follows these principles, do you keep (or at least try) to keep/put the things where they conceptually belong? I'm especially interested in big company applications where you work together with many other people. Clearly you can do whatever you want with your private toy project, invent any kind of an architecture and stick to it. It is not so easy with big projects where lots of people contributed to the software or overall mess.
For example, I happened to see things like UI components going directly to the database to fetch some "missing" extra data which BL does not supply, also both UI and BL working with low level elements like table fields where in my opinion they should delegate these operations to the lower level namely DAL. It was especially sad when after discussing the things with the senior developer guy I saw he didn't see a problem with this at all.
We can of course assume me and whoever shares my point of view are just being perfectionists, but I clearly saw a very disadvantegous consequence in that it took me prolonged periods of time in some of my tasks to trace all the "parallel" routes that the data is travelling to and from the database and to identify whoever and in which way may now be affected by the new functionality I implemented. The way I see it, these are increased further development / maintenance costs overweighting some savings when someone decided to quickly hack the stuff and close the task as soon as possible.
Are you projects "pure" or they abandoned the idea of keeping the clear line between layers a long time ago? If you still keeping it right, how do you deal with colleagues who do not understand these things or don't care about them just building "custom" solutions and hacking hacks all the time? Or at some point in time you stopped fighting with the windmill and accepted it as your punishment?
The more complicated our application gets, the more important separation of concerns becomes.
At 100 klocs, the application was one big blob, as much business code in form classes as anywhere else and calls into form methods from the business classes. With much wailing and gnashing of teeth, we separated out the business logic from the display logic. Any class that needed to notify the user of its progress raised an event that was sunk by the UI. And, for a while, all was right with the world.
Around 200 klocs, we added a data layer. The architecture of our application was such that most of our data was processed as soon as it came in and immediately discarded. Most configuration information was stored in the third-party application with which ours shared a symbiotic relationship. But, settings were starting to accumulate in all sorts of odd corners. We wound up with three configuration management systems, all intricately woven into the business logic. With an extensive rewrite, we were able to separate out the configuration information into its own layer and the handling of streaming data into another layer.
Near the 250 kloc line, we decided to end our relationship with the third-party vendor and make our application stand alone. We began a massive rewrite and, for the first time, added an actual database to our application. Because we had clear lines between streaming information, data storage, and business logic, this was a fairly seamless integration.
Now, approaching 500 klocs, we're moving the application to a grid-based architecture. Not only will the UI be separated from the business logic on a different computer, the actual computation of the quotes and orders that the application sends out will be load balanced and spread out to maximize efficiency. This would be impossible without an n-tier architecture.
At each stage of growth, we were either aided by a clean separation or hindered by our own muddle of communication, data, business, and UI. There probably hasn't been a more important concern than that separation in the creation of this application.