- 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
Dude, you really need to learn about things like workflow engines and process management. You don't "encapsulate all of this business logic in a single layer of code," you model it. Then, it doesn't matter whether input validation occurs in JS or on the server side or on both. It's defined in the same place. There also are no "IF THEN ELSE"s involved. Simply add Actors, Swimlanes and Tasks.
Except that those who have a clue actually do this every day.
If you implement a Business Application in HTML, JS, Java and by directly accessing some DB, if process changes require code changes or refactoring, you're doing it wrong, and you're hurting your customer. That is all.
Admin
"As more business logic “problems” arose, the ERE team pushed the business logic a layer down. Eventually, they found the perfect balance. Using XML “display templates,” they could simply serialize their business entities into XML, mash the two together with an XSLT, and send the resulting XML “display instructions” to the presentation layer to convert into a usable UI. I’ll let you imagine how well that worked out in the end."
This sounds scarily like an existing app I've just had to start working on.
Admin
A good, enlightened article. I especially agree to the concetual Some disagreement:
HTML is a good presentation layer? I don't understand it all, these days almost everybody seems to lose their sanity about productive UI's, in favour of web applications. Have you ever tried to enter an 500 line stocktaking journal into a HTML form? No, I don't say it's not possible to make it productive: see Google Spreadsheets. I'm just saying it usually does not happen as it would require quite an effort. I was already bad enough when GUI apps replaced green screen apps in business, user productivity dropped a lot. Think of a typical SAP R/2 to R/3 upgrade... you usually need a lot more sales assistants afterwards. It's a lot easier to key in a lot of stuff int the green screen. Of course it is possible to do it productively on a GUI as well, as later on some systems like Microsoft Navision managed to basically recreate all the keyboard-given goodiness of green screen apps on a nice MFC gui with all the bells and whistles. But it took a while. Maybe web apps in 5 years will all have Google Spreadsheet-like interfaces for high bandwith data entry, but until that happens, don't call HTML a good presentation layer. You know, it's not just about presenting data, but putting it in and updating it.
Why duplicate logic: why can't just generate the UI layer based on constraints in the database? If only there was a tool that would translate SQL DDL to S-exps or XML...
Admin
I liked this article though I don't work as a programmer. I have worked for ages in the information security field and seen the issues in this article from an auditor's perspective.
What's most troubling is introducing 'artificial' layers like the business logic layer as described in this article. They usually only add to the complexity of the system.
There are not so many constants in this discussion, but there's one from security point of view: system complexity is proportional to the chances that confidentiality, availability or integrity of information go awry in some unexpected way.
And hey folks - that's what it's all about: the customer wants his CIA to be in order and takes no excuses. Keep it simple!
Admin
I visit this website cause, on average, i do enjoy the posts Alex makes on this site. If i find a post that i dont like, i would voice my opinion as to why i didnt like it.. and what i think is wrong with it.
Admin
Has anyone spotted the WTF in this storie yet?
Admin
The use of pseudo hungarian notation in the database naming convention?
Admin
Wow. Just. Wow.
Sure thing, but look what can be accomplish with this handy-dandy glass bottle and some duct tape -- that'll surely pound in the nails, Mr. Goldberg!
Nice article. Its so seasonal, too; all those strawmen really give it a spooky Halloweeny look.
Admin
Anyone who disagrees with Alex's assessment of the enterprise rules engine is a retarded drooling zombie who has no place coding anything and should be a dishwasher at Denny's.
Admin
The definition of business logic is literal and broad, making the article flawed and misleading.
Admin
Thanks for article. I totaly agree with you.
Admin
Business logic [biz-nis loj-ik] (noun):
Admin
CLAP CLAP CLAP (standing ovation)...
I will print this and throw it at some call designers around here...
Admin
One “problem” that was immediately apparent to the designers of the ERE was user-input validation. Certain forms had certain fields that were required in certain circumstances, and end users needed those fields identified with an asterisk. While coding the validation rules in the HTML form’s onsubmit() method would most certainly do the trick, the ERE team found that to be completely unacceptable. After all, business logic had no place in the presentation layer.
Thank you, Alex, for submitting your very own WTF.
Now, if you could just tell me how much do the underlined statements differ from the horror stories posted here about client-side validation and authorization?
Admin
The business layer is not mythical, it's simply done poorly in most instances because most development departments have no definition of what is business logic and what is presentation logic or database logic.
When I separate, I ask myself what I am doing in a class. If my class exists only to enable display, then it's view logic. Sure there's page-flow which is defined by the customer, but it's still the way the interface works, not the way the application processes data.
What about when the class does both, enables a view and implements business logic? The answer to that is pretty simple... your class is doing too much.
Persistence logic should pretty simple. There should be a way to find, create, update, and delete. Anything more than that is business logic.
I have a fourth class, that is utilities. All code that does something that has nothing to do with the application like xml parsing or string utilities(yes I know there are a ton of them them available to download, but this is an example) goes in the utilities.
Everything else is business logic. In my mind, if you correctly define the other three, business logic is like the junk drawer because it's such a broad category.
Admin
Spoken like someone who doesn't know how to program properly.
Go away, troll.
Admin
Steve, shut up. This is Alex's site; quit telling him what to use it for. If you don't like the contents, STFU and don't come here any more. Or, better still, put up your own site that has content you like, and then let us know where it is; we'll all come over there and endlessly bitch about your subject matter, writing abilities, web site design, and forum software. A**hole.
Admin
At what point does the database become more of a codebase. Sure you can stick validation into the db... you could stick the entire application in there. Need to fix a bug... any bug... change a field in the db.
Of course you'd then need to build another application to maintain this monstrosity.
Please try to remember it's a >>data<<base.
The quote mentioned in the article by Michael A. Jackson, seems applicable here. Simply substitute "program" for "database"... "Programmers" for "DBA".
Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.
Admin
I haven't fully digestified everything in this article yet, but I am grateful that it prompted me to go back and read the (excellent) "soft coding" article that I missed before.
That one really is one of my pet peeves. I don't like nothin' soft.
Admin
There really isn't a need for a business layer if you design your programs in a modular fashion.
Sure you might have a few utils/tools/libs that are common by all your programs, but that is about all you need. For example, I have a module that contains a bunch of very common validation routines. This module is easy to find and all my other modules and classes can access it. So there isn't a need for a layer, all you need is just a few classes, functions, and/or stored procedures that are accessible and easy to find.
I strongly agree with re-using code, but I don't see the need for a business logic layer. It just isn't needed.
Even in the some of the very large systems I've worked on (with some that contain over 1000 tables and 1000s more stored procedures) it just isn't needed. In fact, I find that programs with business layers never actually have all the business logic in one place anyway. In every application/website I've worked on the business logic is in the presentation (on forms/pages) and in the database. I find it very simple to modify a business rule in a stored procedure then modify a business rule in a layer.
I know there are programmers out there who try to make the perfect BL but those guys never finish their work and they are always telling their clients that X or Y can’t be done. These guys often find out that their contract isn’t renewed.
Business rules should be placed where they fit best and they should be easy to find and change. That is the only real requirement. Making a layer (a dll) just for the business rules is just more work and more lines of code for you to manage.
Layers suck.
In fact, I’m not even a fan of XHTML anymore. I used to think it was good, but then I found myself hand coding XHTML just so I could hand write (code behind) so that the framework would generate HTML/Javascript. So many lines of code (yes please count all the lines of XHTML) just to do something that can be done in a very simple and direct way using simple scripting. Sure there are advantages to the faked event driven model (that sits on top of a response request model), but it goes against my motto of ‘As few lines as possible”.
Admin
It makes absolutely perfect sense to abstract persistence out of your application and into a black box. If you're writing a persistence layer, you're probably not writing your application.
Likewise, it makes absolutely perfect sense to factor out all presentation code into replaceable components. The reasons are myriad, we shouldn't even have to be discussing this. These are not advanced techniques, these are the basics you absolutely have to know to be productive as a software developer.
I would hope that so far the author and myself would be in agreement. The author's problem seems to be that he does not have a good way to break down "everything else". That's usually because "everything else" requires domain knowledge. As programmers we try to scrape by learning the least we have to about the problem domain, and instead lean heavily on people qualified to properly understand it.
Unfortunately, this means we cannot look ahead and we make some pretty stupid design decisions. A lot of the needless complexity and "over engineering" comes from a poor grasp of the actual problem. Meanwhile, we understand the technical issues very well, and so we quite properly manage to slot them into time-tested patterns.
Anyway, dumb article.
Admin
Why am I 99.9% certain that everyone trashing this article is themselves guilty of creating monstrous abortions of Enterprise Rules Engines that they thought were quite clever....
The key is simply ease of change. If you've ever had a simple request to change something on the display and found yourself having to dig through multiple layers of nested code your system sucks because it is getting in your company's way at that point.
Admin
Alex, that was inspiring! Of course there will be people who say "But I like this-and-that persistence tool just fine and I've done great and wondrous things with it!", while ignoring that what they're doing is fundamentally flawed. You know what? Sod them. I wouldn't mind to see another article like this in a month or so.
Admin
This is exactly the problem. There is a high cost of ownership with multi-layered applications.
Most of these programers are fresh out of university with no practical experience. The profs that teach this crap should be hung or shot and so should all those idiots who write books on that trash. Everyone knows the saying, "Those that can't do, teach"
Admin
I always thought Business Logic was an oxymoron.
Admin
"principle" not "principal"
Anyway, this is why domain languages were invented. If you have a 7-character customer field, that also needs to be 7 characters on a form, then you can use a domain language that tags this piece of data with that restriction. Then you generate database schema and HTML pages from that metadata. And having metadata in a program-readable form makes version updates easy!
And, for the record, perl scripts can make a fine metadata language. Or simple XML. The complication comes where the relation between database and UI is not 1:1. Thus, in your schema, you should have some escape clause, that lets you write code, which is where the non-trivial business logic attachment comes in.
Then there's processing, which we have C++/C#/COBOL for. Hopefully, your metadata can generate convenient data structures and bindings for your data for your language, too.
Admin
This article was terrible. Just because one company designed a crappy business tier does not mean in general we should avoid using a business layer.
Also, this comment is bad:
"no choice but to duplicate, triplicate, or even-more-licate business logic"
Actually, each tier can validate things related to their responsibilities and avoid code duplication. For example, inputting a 7-digit customer ID:
Presentation tier: (1) Make sure it is a string under MAX_INPUT_LENGTH character long. (2) Trim whitespace.
Business Tier: (1) Make sure it is a string of only digits. (2) Make sure it is 7-characters long. (3) Make sure there is a DB table with a primary key matching that 7-digit number.
DB tier: (1) Make sure the primary key is the right data type and fits within the DB column, etc.
Admin
And therein lies the flaw in Alex's (and your) argument: You don't seem to make a distinction between a single instance of a horrendously designed application purportedly dealing with business logic, and the concept of a business layer.
To use Alex's inspired example of mis-using a hammer: Some idiot built a monstrous contraption using a hammer for the ultimate purpose of pounding in nails, therefore hammers are the root of all evil, and anybody who uses one should be shot.
Chewbacca is from Endor, therefore business layer encapsulation is a myth. You must acquit.
Admin
Presentation Tier: How about thinking about the user and telling them right up front that thier entry contained illegal characters instead of having them wait for the response to goto the server and come back. BTW is that MAX_INPUT_LENGTH the system limits on what a text field can accept or the max length of the customer ID?
Business Tier: Here you are again checking the length and if created a nice interface for the user also checking what type of characters the field can store. Also you are checking the database to verify that you are not about to insert a non-unique number.
DB Tier: Since it primary key it is already required to be unique and the database will check for that, it will also check that it is of the right length; lets ignore the chance of you having a check constraint to verify that only digits are entered.
So lets check the duplications.... Length: 3 Unique ID: 2 all but presentation Correct data types: 1, 2 if you have a nice user interface. We are ignoring db check contraints.
So based on your example we have one place where we are not duplicating a logic and for that we make the users have to wait for their response to goto the server get checked and then come back to them. Not sure I would place that as a gain for the programming world.
Admin
Your example is far to simple to even justify such a complex design.
Can you explain why you need to make a Business Tier just to do something that can be done in a single utility function? Why do you need a tier to avoid code duplication?
You should consider a vertical modular design and not huge horizontal layers.
with a layered system you will have to sift through to many areas just to make a single change and your clients will think you are very slow.
For example, in your method if you need to add one field to a form you would have to make changes in many different areas.
I think what alex is trying to say is that you should almost consider each form/page to be a self contained application on its own. The less a section of code requires another module or layer the more modular your application will be.
I would argue that the BLL is a form of duplication. It is an extra layer that isn't needed!
All you really need is one function to call the stored procedure and save the data passed to it.
The more lines of code you have the more bugs you will have.
I have to laugh when people create a DLL called the BLL. BLL.DLL lol... such a waste of time. Exactly what you plan on doing with that extra DLL? Do you really think it will ever be used with a PL and DAL that is a different version? "ok MR Thong, just replace this dll with the one you have and your bugs will be fixed... haha now you know why I took so damn long to finish the application :)"
The business layer is a pipe dream. It creates more problems then it solves and it is nothing but a duplication of effort. What a waste of money.
Admin
I guess after reading this I should rethink my application design that includes multiple business layers. Okay There are so many rules, that putting them all into one layer was becoming too combersome. My design is to have Layers for government regulation rules, state regulation rules and business rules. The current layer has over 10k lines of code and is not as easily maintainable as we would like. Still it is far better than having all that logic in the stored procedures or in the presentation layer.
Wouldn't it be funny if his article was really in each individual page instead of using a url-rewriter and a "persistance layer"? Or... maybe he is.
Admin
Admin
ummm.. that is complete over kill.
why not just have a table, a stored procedure, a save function?
seems to me you are creating too many lines of shit for your program to run through.
I would not want to maintain all that auto generated crap. I could do what you are trying to do in about 10 lines of vb or c#.
Admin
Once I realized this wasn't a spoof, I found it ironic that I received a "WTF" from the author of the WTF site. Thumbs way down on this one.
Admin
Stored procedures are made for business logic!
There is nothing wrong with the business logic in the stored procedure. A stored procedure is in fact the ideal place for business logic. Sql server isn't as good for this as oracle, but does the job rather well. I would rather update a sp and make a quick change then spend an entire day sifting through the logic in a multi-layered application.
As for the PL. How are you going to solve a simple customer request that the drop down list should become visible when the account number entered in the textbox starts with 5553? Seems to me that is a case where the business logic will be part of the form isn't it?
Admin
Maybe the fans of these complicated layers are just bad at databases? It seems to me that anyone actually dealing with lots of changing government regulations would want things like history tables, to store the tax rate or per diem rate at a given time in the past when something used it. Which can really only be dealt with on a database level.
Admin
I agree somewhat. In fact, I would much rather see a framework where common business requirements are processed and generate appropriate code for database, middle tier and presentation.
Such that you only code the fact that a user name exists and is at most 30 characters long in one place. That way if/when you change it, you are sure that nothing was left out.
A well engineered system would use some "good", expressive, high level language (lisp, ocaml, ...) and generate requisite SQL, java/php/perl (whatever you serve with), html templates (or merge with html templates), and javascript.
A subset of lisp or ocaml or ... is easily translatable into perl, java and javascript. A more limited subset is translatable into SQL. I have some experience in generating javascript from lisp, and it's actually pretty cool: you automatically obfuscate clear and short lisp code into unreadable javascript. This can be tailored to deal with browser quirks and generate slightly different javascript for the few main browser classes out there.
Cheers, Kuba
Admin
Admin
Do you have a single example of this working well? Seriously? What if the performance of the auto-generated sql sucks, and your DBA wants to tune the query. Do you tell him "sorry you can't, it's auto-generated"? Where do you autogenerate the appropriate database locking levels to use in your queries? Where do you auto-generate the max degree of parallelism to use in your query? Where do you auto-specify which queries need transactions and which dont? Those things you can really only specify in SQL directly.
Or.... have you never had to deal with those issues because your project is small and not database intensive? I have several shops suffer enormously from this auto-generated code problem when they got big. They either institute a worst of all worlds approach of hand tuning the queries after generation (quickly sucked up all dev bandwidth maintaining what is in effect two systems) or chucked the whole auto generate approach, started with what they had generated and just stuck it in source control and developed from there - regaining their agility.
Admin
You wrote one small application that way. It will work while it remains small. As it grows to medium size the effort to do the generator approach will far outweigh any benefits. As it grows to large size it will utterly collapse. This is the fatal flaw of turing complete domain languages, which they all evolve towards. There are many many excellent general purpose programming languages out there you can use to do your job. Or, you can invent your own - finding all the problems all language developers find along the way. One is quick and easy, and you can find qualified people to work on it. The other is messy, complicated, expensive, and you can't find anyone who knows it, so the learning curve is through the roof.
Tell me - how do you debug a generated file that doesn't work properly? What if you need to change only one instance of thing X and not all instances of thing X? Suddenly you need a superclass of thing X and subclass X1 and X2 and it gets complicated right away. Of course, every developer finds this out for themselves the hard way.
Admin
I just checked to see how many tables and stored procedures are used in the main application I work on: 550 tables and 2,800 procedures. And in the secondary application: 350 tables and 1,800 procedures. And a few dozen views and user defined functions and data types in the db too. And all the DDL in source control thank goodness. I think the "layer" approach generally collapses under its own weight before reaching this size. Or else they have really really huge dev teams. Our dev team is under 20 people for the applications that use these two databases.
Never replicate what a database can already do. Never replicate what a general purpose programming language can already do.
Simple rules I live by.
Admin
The words as a student automatically disqualifies you. Wisdom only comes from experience.
All or nothing solutions stink of 'hammer-nail' syndrome (every tool is a hammer, and every problem is a nail). There are domains where fast paced change requires software that is responsive in up-to-the-minute time frames. Waiting for an overtaxed IT department to come rushing to the aid of a user community every moment is inefficient, and untennable. Conversely, IT dictating user policies is just downright stupid.
Admin
That's a good one for the WTF site. I'm seriously like WTF!? Anyone who says that business logic layers are pointless needs to be smacked and need to grow up.
Admin
Alex did an impressive way to deliver an useful message while was doing WTF inside it :)
"duplicate, triplicate, or even-more-licate business logic", that's kewl, Alex!
What an amazing article after all..
Admin
To all arrogant argumentative fuckers in here:
READ THE FREAKING DEFINITION USED IN THE JOKE ARTICLE:
...fucking wankers... "Oh but if I change the definition of what he's talking about, then he's wrong! I'm so smart, I can argue about something completely irrelevant to the joke at hand in order to redeem the smarty points I lost for not being able to comprehend the text presented to me"
Admin
I'm myself looking at all of this from security point of view. I wonder if it's simple logic that produces the least amount of code, most simple and efficient solution, and thus, least amount of possibilities that something goes awry.
"People suck, machines only follow... "
Admin
Maybe I don't understand the definition of a "process" in this context, but how could this possibly be achievable? If your application has input for weight/height and calculates BMI from it, how do you avoid changing code when you get your first UK client who enters metric data (assuming internationalization was not a requirement when you started)?
Unless you planned for everything that can/will happen in the future, you'll have to change some code. To say otherwise is to say that software development is 5% maintenance and most of it is up front.
Please explain yourself.
Admin
Admin
I recommend the book SQL For Smarties, it may enlighten you. One of the definitions of a RDBMS is that it allows you to put constraints on your data. But if I read what I just wrote, I'd think, "Who cares about definitions?" Well I'll tell you why it's important then:
Don't repeat yourself: If you don't understand the importance of this principle, you're not a modern programmer and you should ignore what I say.
Lets say one day you have to make a brand new application that uses the same database as your old application. If your old application is light on constraints, you gotta write all your constraints all over again or you're going to fuck up two applications when the new one makes a mistake! Less work for you
Don't reinvent the wheel: You could use your code to make sure that foreign keys, triggers, primary keys, check constraints, etc. are enforced, but there have been programmers working for YEARS on these problems and built their solutions into the database that is MEANT for doing these things well. You really think you're going to write something better than them for these things in a month? In ONE year?
Admin
I also think this article is garbage.
That being said, I'd like to give some helpful advice on identifying business logic (this comes from Martin Fowler).
First, assume you're making a web application. Then focus on a block of code. Now imagine you wanted to make a desktop application that does exactly the same thing but LOOKS completely different. If your desktop application could save time by having access to this code, you are looking at business logic! If you would have to copy and paste the code to be able to use it in the desktop app, your business logic is in the wrong place!