- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It's "we software developers". Not "us software developers". The rest of the story was OK I guess.
Admin
Ah, the audacity of telling a website creator what his website is about.
-- James Aguilar
Admin
I always thought business logic refers to changes made in an application purely because the organization or client wants to tweak their business rules. For example, changing the interest rate on a type of loan they offer. I visualize this as a set of dials that a non-programmer could turn without modifying any other code.
If so, column names and some of the other examples would not fall into that category.
Admin
I have no quarrel with articles like this, and I don't mind that they take the place of traditional WTF stories. They link to plenty of past WTFs and identify underlying problems that led to them; they show how to avoid making new WTFs in that same vein; and they're a nice change of pace, a brief time-out from the daily feed of WTFs, in which productive ideas are discussed. Let's have another one some day. Maybe even make this a monthly feature.
Admin
Awesome. Thanks.
Admin
Hear hear!
Good write-up on the pitfalls of over-engineering, because that really is what you are talking about here, over-engineering and the lack of standards.
Business logic comes in two forms, hard logic and soft logic. Hard logic is the fact that you need a first name for every customer, so that logic is duplicated in the database, in the customer class, and on the UI where it tells the user that that info is needed. Soft logic is how much of a percentage to deduct off someones first order. This can change over time and can be set by non-programmers.
Business logic comes in so many forms and a lot of us try to treat it all the same.
Admin
Oh, goody, Alex is going to lecture to us again, just like he did when he changed the name of the web site.
Please, Alex, stick to the funny stuff and don't preach. We come to your web site to laugh, not to have an academic discussion. If you want to preach on a regular basis, create another web site for that.
Admin
Sorry Alex, this article is complete rubbish. I've worked on enough large scale application development to know that not only is a Business Logic Layer a nicety, in a large number of cases its practically a requirement.
And as for 'Persistance Plague' - bollocks. Use a persistance engine like Hibernate/NHibernate, but take your time and design your database properly - preferably with a good DBA in tow.
A well designed system should never, ever, have "no choice but to duplicate, triplicate, or even-more-licate business logic". If you even have to duplicate business logic, you should be asking yourself where you've gone wrong.
Admin
I liked the article, too, Alex. I don't expect those "serious"[1] articles to be too frequent here, but it would be nice to have these types of articles feature on the site. :)
[1] It didn't sound too serious, anyway. Linking to WTFs that shows this make the article more interesting and fun to read. :)
Admin
Mr. Papadimoulis, once again, I'm your fan.
I've been forced to do something like this uber-logic-layer in a solution once, and guess what... If I could go back in time I would have quit that job by the time they asked me to do it.
Admin
Good article. I like the use of business logic when, like all other code, it is not over engineered. At the moment I am working with a good business logic that helps me no end and I love it. It isn't always good, like everything else. If the system is going to be over engineered and full of bugs then whether or not one of the over engineered buggy parts of it is called a business logic layer or not really doesn't change how bad it actually is. It always helps if you remember the basics like Keep It Simple Stupid etc.
Admin
Quoted for truth. I find myself sometimes falling into this situation and its always hard to pull myself out of it and say 'ok, self, just do it the boring way so you can get it done.'
-Diamonds
Admin
I think the last paragraph is almost right, but misses an important point about the strengths of software. It is absolutely true that a "business logic" constraint, such as the size or contents of a field, will need to be specified in multiple places in a non-trivial application. But it is just as important that a good system allow the person imposing that constraint to specify it once, not go groveling through the code to make a dozen changes. There should be code that knows how to translate a given constraint into the appropriate DB schema, Javascript validation, etc. Of course, not doing it that way ensures employment for your QA group and maintenance developers.
Admin
capthca: craaazy
Admin
It's true that not all applications need tiered architecture. But you're not helping. For starters, your examples are completely wrong. Therefore the conclusions that you draw from your analysis are also wrong.
Column names in your database are not business logic (anything having to do with the database is, by definition, persistence tier). Nor is a rule that says "display past-due invoices in red" (anything having to do with presentation is, by definition, presentation tier). Business logic is the stuff that goes in the cracks between the two. For example, "any invoice at least 15 days past its due date is 'past due' for the purposes of reporting." The business tier gets the invoices from the database, figures out which are past due, and gives the presentation tier a list of invoices and whether they are past due or not (rather than how many days past due they are). The presentation tier works out how to display these.
There are stupid ways and smart ways to do a three-tier architecture. Done properly, it benefits reliability, scalability, extensibility, and maintainability. For example, you can have your Web designers change the color used for displaying past-due invoices without any chance that they will also decide it should be 20 days instead of 15. They don't have access to that code, so they can't change it, accidentally or otherwise. Which is good, because your Web designers aren't programmers, and your programmers aren't Web designers.
You'd do better arguing against dumb architectural decisions in general, of which you have found some doozies, but separating things that are different functionally has some very obvious and useful benefits. Don't do a three-tier architecture just for the heck of it, of course. But for big systems that no single person could hope to understand, it's a perfectly reasonable way to break down the functionality.
Admin
Written like a true php or .net developer. I suppose you also think screen mock ups constitute a design.
Admin
I'm working on software right now that requires managers (read: idiots) to be able to design data entry forms in a very much point and click manner that include such complexities as input validation.
Some of these users are people who don't know the difference between a web browser and the internet, so it has to be very, very easy (and it's not quite at that point UI-wise, but getting there).
Point being: Sure, normally I would include form validation in an onsubmit() function in JavaScript and not worry about a superfluous 'business layer'. That's silly. But in this case the business logic is being dynamically defined, and while my system is smart enough that I don't have anything actually generating JavaScript code on the fly (ugh) there is a system similar to the one descript involving XML and XSLT and other things.
In other words, any attempt to do something even remotely similar to ERE is a waste of time, when 99% of the requirements are never going to change, and when there is a developer on hand to tweak things when they do. But is sometimes necessary to create content on the fly according to idiot-customized rules.
Admin
And perhaps a little investigation into things like constraints, triggers, and using the proper data types might help with all that duplicate logic you think is necessary...
Admin
I disagree. I agree that Business Logic layers as you presented are a Bad Idea. But you can have ways to avoid duplicating information like field sizes somehow. You don't need to reinvent storage mechanisms or reinvent user interface mechanisms like on the linked WTFs to avoid the duplication you argue to be unavoidable. There are many possible solutions that are not WTF-worthy or complex to avoid this type of duplication. It could be, for example, a simple solution that asks the database for type information to limit the input length by default on the user interface.
Maybe the big question on each case is if the cost of making a system to avoid duplication will be bigger than the benefit. And I think there is duplication that may be not worth avoiding today. But when you are having the same kind of information duplication on all systems you develop, I think there is something wrong, and it is very likely that the benefit of avoiding it will be bigger than the cost of implementing a non-WTF solution that would help avoiding it.
I think that probably other people will show that there are non-WTF solutions to avoid the duplication of information on your example of field size validation. I just don't know any because it is not the area where I work, fortunately. :)
Admin
Oh, and I should add, the presentation/validation generated from XML templates customized by the managers through a GUI thing works quite well. There are certainly some parts of the software that are ugly (the intern did most of them), but nothing that can't be fixed.
It is a relatively simple example--the degree to which these data entry forms can be customized is limited. But it is an example of soft-coded business logic generating XML to hand to a presentation layer that works well.
Admin
I tend to agree that the article is complete rubbish. You pervert the definition of a business logic layer then proceed to admonish it for its bad design. There's a name for that, Alex -- a straw man.
Perhaps "business layer" is a bad name. However, its a name that professional architects understand and it does NOT include "highlight overdue entries in red." To say that because making overdue entries in red is a business rule, it would go in your twisted definition of a business layer and then extend that argument to say that business layers are horrible because of it is completely disingenuous.
The alternate names you suggest are even worse. "Processing layer" is worse than "business layer". The UI and Persistence layers "process" too. They even process things not directly related to the business rules. "Database layer" is probably the worst of the bunch. To name an architectural layer after a single specific technology is the True WTF. There are other persistence technologies besides databases. There are also kinds of "presentation layers" besides "user interfaces". You obviously only work on web applications where there's a user interface and a database. However, there's more than that out there. You need to broaden your horizons a bit.
As the cherry on top, you finish off your lecture by defining what true layering is (i.e. the actual definition that professionals use), but claiming it to be your preferred expert-driven approach. Love it.
Admin
This is one of the reasons I dislike the term 'business logic' or 'business layer.' Everything the developer writes while employed is likely related in some way to the operations of the business, and Alex rightly points out some of the pitfalls that come from an inappropriate separation of tasks. But what of an alternative that avoids these pitfalls?
I prefer the term domain layer, where the developer seeks to encapsulate as much knowledge about the problem domain as possible. The objects in this layer are usually decoupled from a UI and a mechanism of persistence, but common sense about your project always rules.
Your HTML form onsubmit() may be a great way to handle validations for small and limited systems, but you're only shooting yourself in the foot in a larger system that must accept input from multiple sources. The domain layer is a natural place to consolidate validation information, though you'd be stupid if you didn't also write database constraints and a UI that leads the user toward correctness wherever possible. I think this is the crux of the article: You can consolidate as much as possible, but it's typically unavoidable that systems will have some form of duplicate logic.
Admin
Hear hear! Thanks for that, Chris.
Admin
I confess I'm confused. Why do you visit this website if you don't like its content? Alex isn't a different person today than he was last week when he wrote the article that you wrote a warm, fuzzy comment on. (OK, I admit that was made up.)
The people who read these articles are the kinds of people who recognize WTFs in their own experiences and try to avoid them. As a student, I have to say that a lot of the software-related wisdom I've acquired comes from seeing the bad examples on this site.
So what's wrong with an article once in a while (echo: once a month) that attempts to synthesize all the discussion about horrid design patterns into useful suggestions? (Also echo: the included links were a nice touch)
captcha: stinky. Your comments, not the article.
Admin
SQL Exceptions (formerly SQL Errors) and SQLSTATE are not that clear about it. It's real work to communicate a 5-char SQLSTATE code to application code. (This does not take into account RDBMS vendor specifics.)
Each language is different. Java throws SQLException objects. C reads a global SQLSTATE variable. Don't askk about ADA's SQL Package. The code still has to compare SQLSTATE using IF-THEN, which is duplicate logic.
Those SQLSTATE codes don't point out the exact table & column where a constraint failed. We have to consult INFORMATION_SCHEMA for that, which costs more SELECTS. How do we easily communicate this to users, and have them correct input?
Admin
Unfortunately I think Alex has seen Cargo cult programming too often http://en.wikipedia.org/wiki/Cargo_cult_programming
Admin
I'm not welcome on the site if I think that this article was rubbish? That's pretty bold to say.
Alex's main thrust is generally accurate, but I have serious issues with his approach. Using straw man arguments, distorting definitions, and making suggestions which are demonstrably worse than those he admonishes does more harm than good, in my opinion.
Alex has a soapbox here and that's fine. I'm just a voice in the crowd shouting back, "You aren't as right as you think you are, Alex!" I respect Alex for allowing us to shout back at him in an open forum. Don't get me wrong, I'm criticizing the approach he took in this single article, not Alex as a person.
Admin
I don't have tme to read such a long article. I'm implementing business logic!
Admin
"Unlike so many other entries in the IT lexicon, 'business logic' has no standard meaning."
I disagree. I find many examples of things with no standard meaning. A recent favorite example of this is "Inversion of Control".
From the Wikipedia page, it sounds as though the most common definition of IoC is: "There is very little agreement on what Inversion of Control is."
Admin
I STRONGLY disagree with this article! And I think anybody who has ever done a large enterprise application (communicating with different back-end servers) will disagree.
Alex, read up on http://en.wikipedia.org/wiki/BPEL and http://en.wikipedia.org/wiki/Drools before trashing this style of programming.
Admin
I felt it was a poor article presentation that wasn't clear enough about the problem space to which it referred. Especially when it points at a solution like Prevayler as a bad idea. It's unfair to cast it in a negative light without properly explaining where it SHOULD be used. There is a place for object persistence. I think the scope of the article represents the limited experience of the author making sweeping generalizations about an entire industry that aren't necessarily relevant to everyone else's experience. Perhaps more qualifiers about past experience and making the example more specific to a particular type of problem would have helped.
I don't think it's bad advice in general, but without a broad base of experience, I could see this advice being applied badly in the wrong situations, which would create as many problems as it purports to fix.
Admin
Regarding column names being in the persistance layer and flagging overdue accounts in red being in the presentation layer. All true. But...
Here are two real-life examples that I've worked on. In one case the business needed to keep track of certain attributes of our customers. But the attributes they needed to track were dynamic and could change (theoretically) on a whim. If we embedded these attributes as proper columns in the data model the business would have had ask for changes six months in advance.
In another case, we had a screen of customer data that had some required information. But this information was required by Marketing for research purposes -- it wasn't "required" in the database constraint sense. What's more there were actually two different groups in Marketing that were each responsible for a subset of the customers. And of course those two groups had different ideas regarding which fields were "required". So not only could the list of required fields change, we could also end up with two lists or even more than two lists based on how our customers got segmented.
So I agree with the main point that while a "business logic layer" is a good thing, trying to put ALL business logic into that layer usually ends of as a bad thing. Which is fine, but I've noticed that when you call something a "business logic layer" there are certain very-literal individuals who interpret that as a binding contract of some sort.
Another point is that in most of these cases the REAL problem is that people know that there will be changes but want to avoid the pain of the change process. It's usually easier to get permission to insert a row into a table than it is to change code, so it seems logical to build a system that can be modified by changing data in a database. The fact that this entails at least as much risk is overlooked until after the app goes live.
Admin
The only thing that comes to mind, when reading this article:
http://www.codinghorror.com/blog/archives/000283.html
Unfortunatelly the author of this article seems to have read the information on some funny shaped spraycans (aka code submitted to this site) and now thinks he knows about painting boeings. ;)
This article probably puts a smile on somebody who already has painted a Boeing (or programmed a major software project, spanning multiple "data" sources and having different interfaces, like GUI, Web and Smartclients, plus multiple "painter"), but just imagine my boss reading this - and now thinks as well that we really should get rid of the domain layer to speed up development. That could get pretty ugly pretty fast. Just a thought.
Admin
Interesting Article. I think it's true that you can't completely encapsulate the business logic, but that's true with any encapsulation. I do agree that calling it a business layer is not particularly good.
The real architecture that's successful for what you are talking about is the MVC architecture. An MVC architecture doesn't try to encapsulate all of the business logic, but instead distributes it appropriately based on the function of the module.
First, no reasonable persistence (model) layer has one table and stores serialized objects. Maybe in 1996 this was the best possible solution, but not today. While I am sure there are some WTF projects that try that, it's certainly not what you are supposed to do. A good persistence layer uses an Object Relational Mapper (ORM), like Hibernate for Java, ActiveRecord for Ruby or an SQL Mapper such as iBatis for Java. The duties of the persistence layer (some of which we would both call business logic) is to make sure that data integrity is maintained and to gracefully handle any errors (meaning report them to the controller) including invalid data passed from a controller. Using the aforementioned frameworks, this is more or less already done for you. See the Data Access Object (DAO) design Pattern.
As for the presentation layer, it's only duties (which, again, some could be considered business logic) are to handle IO, and to be user friendly. The view should, in essence, function in the same capacity that a dumb terminal does.
Finally, the controller is the heart of the program, and does contain most of the business logic. In essence, it is the puppeteer, and the model and view are the puppets. It handles control flow, validates input from the view, directs the view on what to display (though in some cases the model will directly control this), and directs the operation of the model. It also handles errors from the view or model, and most of the other nitty gritty details.
With MVC, the controller handles the lion's share of the business logic, but there is no attempt to handle all of it. The idea is to distribute the types of business logic (assuming a broad definition such as yours) into appropriate modules. One thing about the MVC model is that while it doesn't contain all of the business logic, shouldn't contain anything but business logic.
Fedaykin
Admin
Thanks Alex. If the readers of this site don't want to know about the philosophy of design, and enjoy discussing it, they are like l'users who can't take the time to learn the difference between a server and a browser. They are missing the complexity that make things interesting.
That said I wish to add some further discussion points.
The architecture of a site is a function of the size of the site. A five page "brochure" site, a twenty page shopping site, and an insurance company's portal deserve different architectures. Using three layers in all cases is like trying to map all fields to database columns everywhere - useless.
Every layer below presentation should be testable by automated tests. This rule alone can help enormously when defining architecture. An application that can only be tested when completed is a house of cards that can fall when any one of a large number of components fail.
A web application is an interaction. Try to keep it as free flowing as a conversation.
Performance is designed in, not added on. Complexity is the enemy of performance.
Evolution is not bad - evolution without the culling of the unfit is bad. Allow the code to evolve but put in the time to refactor. Without the insight of the Almighty, Intelligent Design does not happen in software.
Planning occurs in multiple stages. A regional road map tells you where you are going, Detail maps see you through the turns, and your headlights allow you to plan for what you can see at the moment. Detailed planning ahead of what you can see is like over-driving your headlights. Things come up faster than you can react to.
Admin
I think you might find Domain Driven Design by Eric Evans an interesting source of ideas about the meaning of "business logic".
Admin
Also, for a concrete example of why a "domain Layer" (thanks to the person that came up with that, it's a great name for a "controller". Anyone who understands MVC and has used Struts 1 knows that Struts 1 is a terrible MVC implementation because a struts action is a blend of view and controller.
I've seen a lot of Struts 1 apps that have "domain" logic in the Struts Actions. This always makes me cringe because it's not "good" MVC and it also unnecessarily couples your applications to Struts. I even did this with my first Struts app because I was in a hurry =) However, later apps always had a discrete domain layer, controller, or business layer (or whatever else you might want to call it) where all of the domain logic of my applications existed, and the only things the struts actions did was to function as a adapter between the real controller and the real view (JSP pages). This made it particularly easy to migrate my apps to other frameworks and thus the slight extra effort was well worth it.
Anyway, the point is that the effort to encapsulate domain or business logic is indeed possible and extremely useful and saying that it's a waste of time or unnecessarily complex just isn't true (unless you don't plan on maintaining an app past the first effort).
Admin
Validation should always be done at multiple steps all along the chain. Having said that, it is nice to only have to specify them in one place.
If you were using hibernate with jsf and seam, you could place your 7 character account number length restriction in the db object. It could get automatically propagated through all of the other layers by the framework.
Duplicating code for something like this is only acceptible if your framework has too many limitations to make not duplicating it worthwhile.
This article gets a solid D- in my book. Way too preachy, and not always accurate.
Admin
The business layer is mythical.
Business logic should be where it fits best. Most systems get so big that you end up dividing your code from other modules/pages/programmers anyway.
I've seen so many programmers over complicate their applications with layers upon layers of trash. One nut I worked with created 4 projects (dlls) in one solution just to display content from a simple database.
I've had big arugments with idiot developers who think that they should always be writing code for the most general case. In effect, they try to solve the problem within the problem, within the problem, and nothing gets done. 1000s of lines of code for something that could be done in 10 lines directly.
When you write your systems it should solve the problem directly. I would rather create (copy paste) 100 pages then make 1 big page with a stupid swiss army knife switch/select statement.
I would rather work on a project that has 100 pages that are basically all the same then a project that has 1 page that does 100 different things. Sure those 100 pages might look stupid when you first create the system , but after some time the system will grow and those pages will look very different.
I agree with alex. Duplication is a good thing when it solves the problem directly.
Coders should really try to reduce the amount of code they write. Usually that means you make one page/form and then use it as a template for all the others. So what if their is duplicate code in each form to validate the account number. You most likely copy pasted it anyway and there is a find a replace feature every editor since the stone age. Furthermore, what happens if the logic for one form should be a bit different? You will have to write another validation script anyway or modify the existing one to do something that is only used in one place. Case exceptions are not good in programs. They are the sign of a bad programer that doesn't know how to keep his logic simple.
You guys that write all this over complicated layer logic and multi-purpose validation code should be shot. I'm so sick of fixing your brain farts. Keep it simple start solving the problem at hand directly. When you program this way it is easy to use your pages/forms for other systems.
Admin
Alex, you argue strongly for sensible design principles and user-centric program design. I love it! It's my favorite article on the site so far, if that counts for anything.
Signed, Technical Writing Geek
Admin
Thanks for the discussion points!
Agreed.
I disagree. EVERY layer should be testable with automated tests. True, this isn't always easy, but at least with a web application, you can use tools such as Selenium to create automated tests of your presentation layer too. Testing is the backbone of any code, not just back end code.
Again, I disagree. Other than gross performance errors (e.g. doing resource intensive operations operations in an inner loop or not using IO buffering) performance is simply not a concern for most applications. It should only be considered after the applications has been "completed" and you have a good suite of tests.
Of course, this is not true when performance is really a design goal (such as in a real time system or an application that will certainly need it). However, if it's not a design goal, then you shouldn't worry about it. You should focus on the most important design goal of any application, correctness and if it's also a goal, maintainability. Once that is done, if it's necessary, you can worry about performance.
I somewhat agree. You can never come up with a perfect design on your first try, but that doesn't mean you shouldn't try. The ability to refactor code is inversely proportional to how badly written the code is in the first place. If you just spew presentation, business and model code in a giant 3,000 line method (I've dealt with WTF code like this) it's faster just to redesign and redevelop it instead of trying to refactor it.
Fedaykin
Admin
I come to your site to learn. And I appreciate this article.
Admin
I do love a good arbitrary layering model.
My favorite is The Web, though. Content and Presentation should be SEPARATE! This sounds so tempting and wonderful, but anybody who's ever actually created any content knows this simply doesn't work. Presentation serves the content, that's the POINT.
Ditto, Presentation and Persistence serve the Business Logic, that's the POINT.
Admin
Thank you, thank you, thank you!
Finally an article I can send to people when I wash their heads about system design ;-)
In the end it all boils down to one thing: try to find the best solution to the problem at hand - NOT the hypest one.
Cheers!
Captcha: digdug - now that is this trying to tell me?
Admin
Thank you, thank you, thank you!
Finally an article I can send to people when I wash their heads about system design ;-)
In the end it all boils down to one thing: try to find the best solution to the problem at hand - NOT the hypest one.
Cheers!
Captcha: digdug - now that is this trying to tell me?
Admin
Back in 2000 I studied Rockford Lhotka's books, Visual Basic 6 Business Objects and its sequel, Visual Basic 6 Distributed Objects. They were an incredible education in the separation of business logic from UI and data storage, presenting what Lhotka christened CSLA (Component-based Scalable Logical Architecture).
Lhotka has since published updated versions of the same material for .Net. I haven't studied these, assuming that the principles of design remain the same across the platform and language changes. And on that assumption I would highly recommend them to anyone wanting to learn how to code robust multi-tier applications.
Admin
Ghetto Edit:
One thing about the MVC controller is that while it doesn't contain all of the business logic, shouldn't contain anything but business logic.
Admin
I already add a link to the article to one of our on-going discussion. Some people at the place where I work really need to wash their heads!
Admin
At first I found myself liking what the article said. However, upon reflection, it's obvious that the arguments can not possibly work in a large development environment.
My company has around 400 developers, divided into god knows how many groups. Each is responsible for solving a problem in a particular domain space. Given the size of the company there is definately overlap between the various groups. In order to limit that we took a SOA approach.
For example, our websites make service calls to build the navigation menu items. Anywhere else I've been I would have fired the architect/dev that came up with such an architecture. But then again, every other company I've been at had less than 10 developers.
Here, it is absolutely mandatory to keep us from shooting each other in the foot. The various systems have published and well known interface contracts. We have versioning of those interfaces as well as versioning on the implementations. Also, development is done is 3 different programming languages (c#, java, and c++)
Although I do get the point about over architecting. One recent project here was to tie an existing website to an existing web service. This took 2 more web services, 8 workflows, 6 biztalk orchestrations, over 30 sub projects in the solution, and close to 3500 man hours to complete. Just to be clear there were only 4 simple methods which needed to be called.
Admin
If I found a large application that followed Alex's advice to "duplicate, triplicate, or even-more-licate business logic", I'd submit it to the WTF.
Few things make a system more tedious to maintain and error-prone than cut-and-paste coding. Or worse yet, completely re-implementing the business logic as you add access methods: web services, wizards, import and export functions, upgrades from previous versions, etc.