The Mythical Business Layer

  • gabba 2007-09-25 13:16
    It's "we software developers". Not "us software developers". The rest of the story was OK I guess.
  • How about this option? 2007-09-25 13:17
    >Your site is about interesting stories sent in by readers that have interesting "WTF?!?!" stories to tell, or intriguing error messages.

    Ah, the audacity of telling a website creator what his website is about.

    -- James Aguilar
  • antonrojo 2007-09-25 13:18
    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.
  • Andy Goth 2007-09-25 13:20
    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.
  • Steve L. 2007-09-25 13:24
    Awesome. Thanks.
  • KattMan 2007-09-25 13:24
    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.
  • Steve 2007-09-25 13:30
    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.
  • IceFreak2000 2007-09-25 13:30
    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.
  • Eduardo Habkost 2007-09-25 13:32
    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. :)
  • Renan "C#" Sousa 2007-09-25 13:33
    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.
  • Bob 2007-09-25 13:38
    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.
  • Diamonds 2007-09-25 13:39
    The Enterprise Rules Engine and the Persistence Plague are fueled by two factors: bored and clever developers, and dangerously poor semantics.


    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
  • scifi 2007-09-25 13:40
    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.
  • Dividius 2007-09-25 13:48
    IceFreak2000:
    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.

    So... how do you address the issue Alex raised re: the order number? Does your well-designed application just use varchar(50) for the column definition and blindly pass in any user input to realted BLL methods? Or does it define char(7) not null, and do server+client-side validation of the data entry?

    capthca: craaazy
  • kindall 2007-09-25 13:48
    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.
  • T604 2007-09-25 13:48
    Written like a true php or .net developer. I suppose you also think screen mock ups constitute a design.
  • Hyuga 2007-09-25 13:49
    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.
  • Bob 2007-09-25 13:50
    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...
  • Eduardo Habkost 2007-09-25 13:51
    A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.


    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. :)
  • Hyuga 2007-09-25 13:55
    Hyuga:
    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.


    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.
  • M L 2007-09-25 13:58
    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.
  • Chris F 2007-09-25 14:00
    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.
  • M L 2007-09-25 14:07
    Chris F:
    I prefer the term domain layer, where the developer seeks to encapsulate as much knowledge about the problem domain as possible.


    Hear hear! Thanks for that, Chris.
  • Anonymous coward 2007-09-25 14:14
    M L:
    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.

    ...

    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.


    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.
  • Andrew 2007-09-25 14:17
    Bob:
    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...


    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?
  • Anonymous 2007-09-25 14:19
    Unfortunately I think Alex has seen Cargo cult programming too often http://en.wikipedia.org/wiki/Cargo_cult_programming
  • M L 2007-09-25 14:22
    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.


    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.
  • Michael 2007-09-25 14:24
    I don't have tme to read such a long article. I'm implementing business logic!
  • tk. 2007-09-25 14:25
    "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."
  • Alan P 2007-09-25 14:30
    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.
  • genki 2007-09-25 14:33
    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.
  • JPLemme 2007-09-25 14:36
    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.
  • T 2007-09-25 14:39
    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.
  • Fedaykin 2007-09-25 14:53
    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
  • verisimilidude 2007-09-25 14:55
    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.

    1) 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.

    2) 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.

    3) A web application is an interaction. Try to keep it as free flowing as a conversation.

    4) Performance is designed in, not added on. Complexity is the enemy of performance.

    5) 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.

    6) 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.
  • Matt Savage 2007-09-25 14:57
    I think you might find Domain Driven Design by Eric Evans an interesting source of ideas about the meaning of "business logic".
  • Fedaykin 2007-09-25 15:05
    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).
  • Jess Sightler 2007-09-25 15:06
    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.
  • xboob 2007-09-25 15:12
    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.

  • athloi 2007-09-25 15:16
    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
  • Fedaykin 2007-09-25 15:19
    Thanks for the discussion points!

    verisimilidude:


    1) The architecture of a site is a function of the size of the site.


    Agreed.


    2) Every layer below presentation should be testable by automated tests.


    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.


    4) Performance is designed in, not added on. Complexity is the enemy of performance.


    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.


    5) 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.


    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
  • Se1f Aware 2007-09-25 15:20
    I come to your site to learn. And I appreciate this article.
  • amolitor 2007-09-25 15:22
    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.
  • Da' Man 2007-09-25 15:23
    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?
  • Da' Man 2007-09-25 15:23
    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?
  • FredSaw 2007-09-25 15:25
    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.
  • Fedaykin 2007-09-25 15:28
    Fedaykin:
    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.


    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.
  • tamosius 2007-09-25 15:33
    Da' Man:

    Finally an article I can send to people when I wash their heads about system design ;-)


    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!
  • Chris Lively 2007-09-25 15:33
    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.
  • zompist 2007-09-25 15:40
    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.
  • Anonymous 2007-09-25 15:43
    If you suck as a developer, this is what n-tiered development and business logic layer appears to be all about. Everything described in this article that is "wrong" with a business logic layer are stupid things that developers that suck would do. Of course they are wrong! But it's not because they followed a paradigm; it is because they interpreted it too literally, likely due to their lack of experience.

    Compare the alternative in the given examples: static pages with probably a ton of server side includes. Embedded DB query strings that you have to "search and replace" when you find out your Access back-end database can't scale or your customer really wants Oracle instead of SQL. Good luck keeping your job if that is the way you roll.

    captcha: stinky
  • poochner 2007-09-25 15:44
    Copy and paste is usually a bad thing. I hope you're exaggerating when you say you'd rather copy and paste 100 pages than have one that has a big switch in it. Of course, if you really need 100 different things to happen, you should probably step back and rethink what's going on. And learn the difference between "then" and "than."

    (If you're a non-native speaker of English, you're otherwise doing damn well, I have to say.)
  • FredSaw 2007-09-25 15:53
    poochner:
    And learn the difference between "then" and "than."
    Don't forget principal versus principle. But we knew what he meant, didn't we.
  • webhamster 2007-09-25 16:01
    Wait. You get specs???
  • eyrieowl 2007-09-25 16:02
    there's some valid complaints buried in a load of rubbish in this article. c'mon, now, relying on text-search tools to guarantee your "even-more-licate" business logic all gets updated when the requirements change? maybe...MAYBE if a single developer developed all the duplicated business logic up front, a search tool might find all the instances of that same logic when it needs changing. but if you have multiple developers implementing that same logic all over the place, some better than others, in different languages (javascript, java/c#, sql, etc), almost certainly with different spellings and variations, how in the world do you realistically expect to manage that with text search tools? thank god you don't design standards for any of the systems i interact with....
  • will 2007-09-25 16:08
    Not duplicating logic leads to horrid experiences for the user. There is no reason the average user should have to hit a submit button then wait for a response from a server to tell them that what they entered needed to be a number not a character.
    A system that does not provide a real-time validation,excluding a requirment not to, and then does not verify the entry at the server level(will ignore the database doing checks) is just asking for problems and is just plain user unfriendly.
    While having to go around and make changes at all the levels because a field changed from 5 to 10 characters is pain it does provide a better experience for the user.
  • sf 2007-09-25 16:20
    IceFreak2000:
    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.
    I agree. A few good points are made, but there are so many thing wrong with this article I don't know where to start. Although the examples given in the article are true examples of WTF'ery, they should not be viewed as indictments of the good practice of separating and encapsulating domain, presentation, and persistence concerns. Ignoring proper layering when developing one-off applications for small to mid-sized companies may not pose that big of a problem, but this approach won’t scale in a large enterprise environment with numerous applications interacting with a sophisticated business domain.
  • barf indeedy 2007-09-25 16:20
    zompist:
    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.


    Ha, sounds like this legacy VB global-madness application I'm working on...
  • MAV 2007-09-25 16:39
    *sniffle* it was like the voices of a thousand angels just sang a song of redemption at my front doorstep.
  • Jess Sightler 2007-09-25 16:51
    Not duplicating logic leads to horrid experiences for the user. There is no reason the average user should have to hit a submit button then wait for a response from a server to tell them that what they entered needed to be a number not a character.
    A system that does not provide a real-time validation,excluding a requirment not to, and then does not verify the entry at the server level(will ignore the database doing checks) is just asking for problems and is just plain user unfriendly.
    While having to go around and make changes at all the levels because a field changed from 5 to 10 characters is pain it does provide a better experience for the user.


    Yes, implementation of the validation should obviously be duplicated on the client. But a smart framework will do a lot of this for you.

    Ie, implement the validation on the server and have it generate javscript form validation automatically.

    There are off-the-shelf frameworks that do this pretty well.
  • tamosius 2007-09-25 16:52
    hmm.. am I not getting something, or you haven't read article?
    What I understood (knew) were:
    - do not over architect (over complicate) solutions
    - business layer is a wrong term

    simple as that, right Alex? ;-)
  • I can has clue? 2007-09-25 16:58
    Excellent article.

    My personal pet peeve are people who think database constraints such as column names, type constraints, foreign key constraints, etc. are NOT business logic. WTF?

    I always tell them, if the DB doesn't contain business logic, then why can't I just point our app to a different app's DB and still have it work? You know, like swapping a class implementation.

    I guess they think that business logic is procedural code. Business logic can be declarative too!

    That's another pet peeve: so much in IT is just made-up words with fuzzy meaning. It's like, you know how doctors or engineers "dumb things down" when talking to laypeople? Well, these IT professionals talk that way TO EACH OTHER too. Yeesh.
  • Beau "Porpus" Wilkinson 2007-09-25 17:05
    Will you marry me?
  • Developer 2007-09-25 17:25
    Last time I checked (3 years ago) the "do not over-engineer" principle was explicitly set out in Extreme programming. So there is nothing new here.

    Still there is obviously a benefit. Principle duplication does a good job of educating people who just scratch the surface, because they have no free time for in-depth digging (perhaps, busy with over-engineering or have too many kids to support).
  • hd 2007-09-25 17:30
    gabba:
    It's "we software developers". Not "us software developers". The rest of the story was OK I guess.


    Good lord, get a life.
  • Zygo 2007-09-25 17:42
    Andrew:
    Each language is different. Java throws SQLException objects. C reads a global SQLSTATE variable.


    You say that like there was only one C implementation.

    Maybe somewhere in the ANSI standard there is a definition of such a variable for an ancient, evil, preprocessor-based embedded SQL language.

    In my experience, though, every RDBMS access library, as well as every ODBC-like layer on top of such a library, including ODBC-like generic data access layers built out of other ODBC-like generic data access layers, puts its SQL error state in a different place, even if these libraries are all written for the same language.
  • JOHN 2007-09-25 18:00
    IceFreak2000:
    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.



    I agree completely. My company right now has an amazingly flexible BLL which allows us to have a turnaround time of mere hours for any of our hundreds of customers.

    The love it, we love it. We're raking in cash like there's no tomorrow.


    Don't write an article bashing a concept just because you're not good enough to figure out how to make it work.
  • Corporate Cog 2007-09-25 18:04
    xboob:
    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.


    Many of the comments here bring to mind Martin Fowler's quote in his book Refactoring: "by eliminating duplicates, you ensure that the code says everything once and only once, which is the essence of good design."
  • JOHN 2007-09-25 18:06
    Dividius:
    IceFreak2000:
    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.

    So... how do you address the issue Alex raised re: the order number? Does your well-designed application just use varchar(50) for the column definition and blindly pass in any user input to realted BLL methods? Or does it define char(7) not null, and do server+client-side validation of the data entry?

    capthca: craaazy



    Validation is a mathematically simple operation. In our analysis of software, we've determined that over 80% of all validation is simply requiring a field to be filled in, or be a certain length.

    As such, it is incredibly easy to put together a code factory that relies on given rules defined in the database which automatically generates javascript code for the client tier, and C# code for the business tier.


    No duplication needed. Want to change a business rule? Pop into the database, change a field, voila, done in 10 seconds.
  • Fedaykin 2007-09-25 18:10
    See:

    Ruby on Rails
    Grails
    Some other Java frameworks

    Most new frameworks will generate validation code directly from database constraints and/or from annotations on data objects.
  • 8===> O-X 2007-09-25 18:22
    8===> O-X
  • AdT 2007-09-25 18:29
    There are ridiculous extremes but to me it seems these extremes derive from a lack of understanding (or odd understanding) of what separation of concerns is good for. Separation of concerns decreases coupling and thus improves maintainability. If you've ever had to fix a bug that was copy&pasted into 60 different source files, or ever had to change the type of a member variable (or remove it entirely) that 29 other classes access directly, you know what I mean.

    Another important advantage of separation of concerns is re-usability. I had once written a file utility that used a textual user interface (similar to curses) and one day I decided to make a GUI version of it. Because I hadn't spent any effort separating presentation and logic (or processing if it makes you happy, Alex), I failed spectacularly despite intense efforts. At one point I decided that a complete rewrite would be easier, but I never got around to that, so ultimately there was no GUI version .

    The problem is that re-use can be misunderstood as "every component of your application has to be designed to be usable in another application, too" - you could call it the Kantian approach. This will inevitably lead to confusing and outright bad software. Instead, the goal should be to separate the parts that can be re-used cleanly from the parts that you probably will not be able to re-use anyway. The generic components should not depend in any way on the specialized components, but the converse is permissible and to some degree inevitable. (This means it is still a good idea to make the specialized component depend only on the generic component's well-defined interface, and not its implementation.)

    When it comes to the three-tier application design, which I consider invaluable, the goal should be to separate the code into:

    1. General persistence code, example: ADO.NET, NHibernate etc.
    2. General business logic code, example: undo/redo manager
    3. General UI code, example: WinForms and custom but generic widgets
    4. Specialized persistence code, example: database abstraction layer for a specific database layout (most likely application-specific)
    5. Specialized business logic code, example: bank account processing
    6. Specialized UI code, example: Forms and views for a certain application

    As you can see, some of the examples include code that's part of the .NET framework (and similar components are found in almost any application development environment) or existing add-on libraries. This is intentional, and it is intended to show that unless you have something generally useful to add to these layers, you do not need to write components of this category, you can just use what's already available.

    Incidentally, among other things, I am developing a web interface for administrating certain HTTP-based server software, and about two weeks ago I decided to separate business logic and HTML presentation from one of the dynamic pages into two different modules, one which does the "processing" and one which generates an XML document and transforms it to HTML using an XSLT stylesheet (the module I had previously hacked together just printed HTML code while doing the processing). A week later, my boss asked me to provide an XML web service for this functionality. If presentation and business logic were still in the same module, I would have to separate them now because I need to use the same logic for two different interfaces (one which is HTML-based and one which is XML-based). Moreover, since I am now using XML with a stylesheet to display the result, I can simply make the web service return the same XML document without applying the stylesheet. This will make it easy to parse in the remote component that will be using the web service.

    While in this case, layering was more of an afterthought, I think there's a certain limit to the complexity of any one component beyond which post facto layer separation requires more work than rewriting the whole thing to use separation of concerns from the start, and of course the rewrite gets more expensive too. So while you can sometimes afford to have components that span more than one layer and separate them only when needed, if you miss the opportunity to refactor the code before it grows out of hand, the component can become an impediment to project growth, maintainability and extensibility.

    As a final note (I promise!), you seem to be confusing "business logic" with "application-specific". These are orthogonal concepts. A parser for a certain language, for instance, would be a business logic component, but not necessarily application-specific (in fact, if it's well-designed, it will be application-neutral). On the other hand, a preferences dialog would be an application-specific presentation layer component.
  • nwbrown 2007-09-25 18:36
    So the WTF is that a web site owner thinks he is the world expert of software design?
  • Anonymous 2007-09-25 18:42
    nwbrown:
    So the WTF is that a web site owner thinks he is the world expert of software design?


    I think that pretty much sums it up.

    Now I have to wonder if the URLs on this site really go through some sort of re-write engine or if all these pages really are static .aspx pages.
  • Farmie 2007-09-25 18:58
    nwbrown:
    So the WTF is that a web site owner thinks he is the world expert of software design?

    Lots of people think they're the world expert of software design, but it's not until they come up with idiotic ideas and proclaim them as genius that it becomes a WTF.

    But seriously, I totally agree with you Alex. In fact, I have an idea for your next article. You need to dispel the myth of this useless "Object Oriented" junk. I mean, we waste all our time creating and managing objects when we should just get down to business and write the code, plain and simple!
  • John not John 2007-09-25 19:01
    Annonymous:
    Now I have to wonder if the URLs on this site really go through some sort of re-write engine or if all these pages really are static .aspx pages.

    No, but most of the comments are.
  • poochner 2007-09-25 19:05
    FredSaw:
    poochner:
    And learn the difference between "then" and "than."
    Don't forget principal versus principle. But we knew what he meant, didn't we.


    Yes, I did, and that one doesn't make my skin crawl like then/than does so I don't notice it nearly as often when it's there.

    back to the topic ... So how do we create a central business rule to validate this? Some horrible regex WTFery that looks for comparatives and either then or than shortly afterwards? Who wants to sign up for that one?

    Don't everyone raise their hands at the same time ...
  • JarFil 2007-09-25 19:21
    Great article... and some amazing comments. Not all of them the good kind of amazing, though.

    Some people seem to get mixed up about two terms:
    * specification
    * implementation

    While any kind of duplication at specification level would prove catastrophic when trying to make any changes, duplication at implementation level is a MUST for both a good user experience and a well secured application (aka: good software). That leads to a third element: tests, which are the correct way to join a specification with no duplication, to an implementation with more or less duplication. Any time specification logic changes, all tests should fail. Any time some implementation logic changes, it's test should tell you if it complies with specifications. It's as simple as that.

    All this talk about having a "good" framework -or whatever- in order to get rid of logic duplication at the implementation level, for some kind of "big enterprise applications"... it just gives me the creeps.

    Of course, if your "specification" is actually your implementation, you may be in bigger trouble already. That is, unless your project is some kind of free software with more developers than you actually need (think: linux).
  • richardchaven 2007-09-25 19:45
    gabba:
    It's "we software developers". Not "us software developers". The rest of the story was OK I guess.

    We software developers, we happy software developers, we band of brethren....
  • Jeb 2007-09-25 20:10
    Lay off the crack pipe grandpa and get on with the funnies.
  • Abraxis 2007-09-25 20:20
    As "Enterprise IT architect" (WTF job-title ;-)) I found this somehow little misleading. For me BLL is layer of code between DB (persistence layer) and presentation layer (typically some web framework with simple validation rules for fields like "email", "int x; 0 < x < 10" etc.).

    OF COURSE that DB and pres.l. has business logic - but what I mean by BLL is "everything else" - "grey-validation-logic" (e.g. inter-screen), service orchestration (on submit of this form call this web-service and according to the result display this or this form) etc. The whole idea is, that DB should contain ONLY data-related BL (in ideal world only table constrains with no triggers) and pres.l. ONLY field-validation-BL.

    By using this 3-layer approach you can prevent having complex BL in javascript validation rules or DB stored procedurs - which is sometimes maybe easier to develop, but nightmare to maintain and extend.

    But as all in IT - it's about people and how work...
  • Zygo 2007-09-25 20:23
    There's lots of stuff that annoys me when people who try to create abstract models of real world systems.

    The definitions of the layers are relative. All systems that grow eventually grow to the point where they all have all three layers within them. For example, an RDBMS has a persistence layer (this writes data on disks in a way that survives crashes and power failures), a presentation layer (this allows you to cast a timestamp to a string and catenate it with other text), and a business logic layer (this implements things like foreign key constraints on tables). Just to make life interesting, most of the time the business logic layer is programmable by end-users (an RDBMS's end-users are DBA's and software developers). As soon as you're writing a web application, all of the RDBMS's layers instantly compress into something some people call "the persistence layer," and some people refuse to use the other two thirds of the RDBMS's capabilities even at the expense of maintainability or performance.

    The real practical problem with business logic is that it wants to run all over the place, and those places speak different languages. You can build a three-tier application that does all input validation at the database--it'll work, but the user will often be stuck with little error feedback beyond "an error occurred." To get a text field length limit constraint on a web-based order form, you may need to express the constraint in SQL, C++, and Javascript simultaneously; however, you often don't want to literally do this as it raises the system's maintenance costs by a factor of three (and increases the probability of a bug by 0.3% per line of code that you do this with, if you have the industry average 1:1000 bug:line-of-code ratio).

    Of course, programming in the small is different from the large. A 1000-line application is so easy to maintain and debug that it's probably OK to mix the layers so thoroughly that you'd need a centrifuge to separate them again. Your application will probably have one or two bugs, so you just fix them and you're done. For large programs life is not so easy.

    One tempting solution to this problem is to force the constraint code to actually live in one of the three layers (which aren't really "layers" so much as just where the physical barriers between the system components happen to be). That leads to things like security holes from Javascript forms implementing the one and only data validation in a system, or awful performance because the only part of the system that can do validation is the database, or awful interoperability because all interactions with anything have to be forced through a middle-tier C++ library (which implies you have to support a C++ runtime in your code, which might or might not be easy to do) that contains the validation code. It's a really bad idea to do this--each layer is good at doing some things and not doing others (if that wasn't true, you wouldn't bother with the hassle of having the layer in the first place), so it's an obviously bad idea to pick one of the layers and force it to do everything.

    Another more practical solution to this problem is to create a compiler for a fourth language that generates code in the other three, or write an interpreter for a fourth language that runs in the other three. When amateurs attempt this, you get one or more WTF postings (usually because it's the first time the amateurs have tried to wrap their heads around the rigors of writing compilers or interpreters, not because it's a bad idea in general). When professionals do this, you get enterprise software development tools (although sometimes you also get a WTF posting anyway).

    Regardless of the quality of its implementation, by following this approach you end up with a fourth programming language, and you were probably going insane from having to manage three languages before, so it doesn't sound like a very good idea. Actually, it really isn't a good idea, unless you can refactor your project so it is mostly coded in the fourth language except for well-defined, stable libraries of code in the other three. Frankly, if you are actually capable of successfully achieving this, then you might as well get out of whatever business you are in, remove all the "business logic" from your code, and start selling it to people as an enterprise software development toolkit--everyone else, just buy it from those who succeeded in building it.

    Alex's "solution" of simply coding the business logic everywhere and anywhere it touches program control flow is akin to programming all your applications in assembly language because the only C++ compilers you've ever seen are a bunch of students' CS467 projects (and not from the students who passed the course, mind you).

    Now, there's nothing wrong with assembly language per se, but it's not for everyone or for every project. There are lots of programming tools available which, although not as flexible as assembly language, do provide increased developer productivity through automation. Every higher-specialization language that does this removes some generality from the lower-specialization language that it was implemented in, and constrains developers somewhat--but it also frees them from having to cope with some of the implementation issues that are irrelevant to specialized problem domains. Taken to the extreme, we would expect every problem domain to end up with its own programming language--and to some extent this is what happens. Just look at the number of large, mature applications in the field that have some kind of scripting automation in them.

    At the moment many developers only have access to tools for "business" applications that are akin to assemblers or LISP/FORTH interpreters. It's no wonder they think there's no better way, because they've either seen nothing better, or seen only early failed attempts at doing better. The privileged few who actually do have something better either developed it themselves for interal use, or they are using an enterprise toolkit that most developers have never heard of.
  • Fred M. 2007-09-25 20:31
    I second that.
  • wake 2007-09-25 20:34
    Oh no. Copy-paste programming. Sure, sometimes you can't get out other way, esp. in hurry, but with decent time and budget it soon pays off to refactory and reduce/eliminate duplicities. WhY? Changing thing at multiple places increases (geometrically) the risk of forgetting one occurence or changing the same thing differently on different places. Consequences apply too. Today, with all the ORMs, smart widget libraries, opensource (so you can hack the tool if it doesn't fit and the blame is positively on the tool) there's no reason for hand-coding. Or, better, hand-coding more then once. Just my two eurocents...
  • Abraxis 2007-09-25 20:49
    I think that's the point - just use technology the way it's meant to be.

    Just because it's possible to write your complete project as PL/SQL functions, it doesn't mean that it's really good idea ;-) And believe me - we got few of these projects in our company (not so small bank) and maintaining those is really pain in the ass, I mean in the wallet ;-)
  • phx 2007-09-25 20:51
    "Layers" and "Tiers" are an extension of people that understand Seperation of Concerns trying to explain to newbies how to design their applications.

    You end up with two types of WTFs in "Enterprise App" design:
    1) The newbies that follow golden rules but not understanding why (and the rules can sometimes be incorrect or unsuitable for the situation).
    2) The Great Masters of Theoretical Architecture (that dont realise that while in theory it might be nice for the software to cope with the sun going supernova, it probably doesnt matter).

    In fact you can pretty much tell these people by:
    1) They use the Microsoft Data Access Block, because its from the Enterprise Library - however the only function they ever call is .ExecuteDataSet(...), sometimes putting the results in a hacked up "Business Object".
    2) They use some ORM tool* thats more difficult to use that the space shuttle... but its THEORETICALLY IDEAL.

    I'm not enjoying my current contract, 2 months maintaining a category 1 system. Specific instructions not to change any of their "best" practices. Oh, and for those that recall - I am back at the contract which has a "Kleptography" library - written by a self professed "Klepto" expert who has implemented a bloody Turning Grille^ cipher to protect critical business data. Hilariously I found some of my RSA based shit "refactored" to use the "Enhanced Klepto" library :(

    * This doesnt include the good ones like Diamond Binding which I have used and loved in the past... mainly because they keep their Goddamn Shit out of the other parts of my application and just let me get to my data in plain objects in a sane fashion, without me having to a) write any code and b) have my app crapped up with codegen.

    ^ A cipher which is basically used to teach noobs cryto visually - and is considered weak as fuck.
  • mustapha 2007-09-25 21:12
    This article fails because it makes n-tier design the issue, and not the cargo cultists littering the world with stupid un-tiered systems. I've worked on innumerable 'enterprise' applications where the tools in charge have created a supposed n-tier system but which was in reality a god awful mashing together of different strains of shit. I've also worked on some good systems. The problem is the idiots, not the principle.

    Making the design the focus over the idiocy has negative implications for the authors competence and experience.
  • Muddy Mudskipper 2007-09-25 22:18
    Wow. This site just dropped about 20 points in my mind. "Complete rubbish" sums it up nicely.

    There's a pattern for this recommendation, and it's very common -- The Big Ball of Mud http://www.laputan.org/mud/
  • ActionMan 2007-09-25 22:25
    Bob:
    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...


    How are those concepts going to implement javascript code to provide client-side validation?

    Client side validation isn't required (as the back end should have the final say as to whether something is valid), but it sure does make for a much more usable UI. This means duplication of logic...
  • Jon Gilkison 2007-09-25 22:45
    This is brilliant on so many different levels. Death by design patterns.

    The ERE article was brilliant too.
  • Anon 2007-09-25 23:01
    I can understand where the author is coming from. However, I use a domain model and service layer for every project now -- I don't think I could ever go back. No matter what the size of the application, I find it a ridiculously easy way to quickly evolve an application that I know can scale and will be robust indefinitely.

    http://martinfowler.com/bliki/AnemicDomainModel.html

    No, my domain model isn't anemic, but it's close since I usually can't be bothered with data transfer objects as well as business objects. Regardless of where you decide to balance your business logic, the key is that you have a service layer. This becomes the API for your application, defining the set of operations any external concern can use. Nothing touches your database directly, nothing is done to your system without going through the interface your team has designed. This includes your primary interface, whether it's a web site, windows forms, or mobile device, and any external applications integrating with yours.

    http://martinfowler.com/eaaCatalog/serviceLayer.html

    This doesn't preclude having business logic in the UI. It's virtually essential for a user friendly UI to know that a field is required and must be five characters long before the user hits the submit button. However that logic needs to exist in the service layer or domain model as well, for a number of reasons...

    o When there's 15 pages that use that part of your domain model and service layer, but only 14 check that particular field has been provided and is five characters long. An exception is still thrown, albeit not as nicely as it could have been.
    o When another concern wants to talk to your application, the rule isn't forgotten simply because the original UI isn't involved.
    o When your interface is thrown away, redesigned, or completely new sections are tacked on, you can be assured that no business logic is lost and that no matter how roughly the new interface is done, the application will still continue to work perfectly. (Well the UI might not work perfectly, but no data is getting lost or corrupted.)

    Once you have frameworks in place to support this kind of design, which ideally use some of the fantastic tools out there like NHibernate to run your persistence, there's virtually nothing to do except write your business logic *once* and then get to work on your UI. You can copy some of the business logic into the UI later to get rid of some of those unfriendly service layer exceptions, but the important thing is that a rough version is up and working quickly, ready for the user to fiddle with and start providing feedback on, without compromising what I consider to be essential enterprise application features right from the start.

    The OP might cry, "Aha! See I told you! No single layer can hold all the business logic." I guess I would have to agree. The domain model and service layer do share the business logic between them, and the UI will duplicate some of the business logic. My point would be to never rely on the business logic in the UI. It's there for user friendliness only, not to protect the application.

    One last thing I'd like to say... Why use an OODB or something that tries to make a RDBMS into an OODB? There are fantastic tools out there that map a domain model to a RDBMS perfectly well. Searching for all A objects with B property like 'C' when the objects are stored as blobs just makes me shiver.
  • Ata 2007-09-25 23:55
    1. Article is there for people to read and comment, otherwise why the comment section.

    2. If you agree on some point, doesn't mean you agree on all other points too.
  • spikeless 2007-09-26 00:07
    Dear god Alex, what a poorly informed, out of touch article.

    The primary reason for a domain layer is ease of maintenance.

    How on earth do you maintain or debug an application with business logic scattered throughout the solution? If you have to make a change to one business rule how do you know when you have changed every instance? Duplicate code is a code smell, triplicate is an outright stench.

    The open source community has embraced persistence engines in Hibernate/NHibernate and many others. Microsoft has also embraced this paradigm in their Entity Framework. Either they are wrong or you are. I know where I am putting my money. Some persistence engines are better than others but none that I have seen will encourage you to store all business objects serialized in a single table and most recommend using other retrieval methods for reporting. In my opinion most actually encourage better database design by pushing the design to match the actual data being stored.

    It's poor programmers with this attitude which keep the good programmers in business - cleaning up other peoples unmaintainable crap. I dearly hope I never encounter any of yours.
  • KozMoz 2007-09-26 00:14
    The whole thing about blobs in database records and OODB's/Persistence, is that its basically an unsolveable problem.

    There is no way to deal with transmission (be it over a network or to and from a database) of an object except via serialization. You can try splitting the object into fields and writing 'translator' methods that move the object class to and from a relational form - and you will go insane.

    However, there are times where even with OO schemes you really do need the advantages that relational DB's bring - indexing for one thing!

    There is no path except compromise in this particular minefield, you have to decide which fields are going to be broken out and made fields in the record, and which are to remain purely part of the class.

    One design goal that helps is to try and make sure that the only place the two meet up again is in memory - but then you also have to serialize the 'external' fields when you transmit the object over a network, that's one of the gotchas.

    One interesting approach is to use a relational database as a 'viewer' into a persistent OO system, but again it depends on things, eg. is it essential to have covered ALL cases (eg. when making an airline booking) or just SUFFICIENT cases (eg. when finding storage bins with space).

    Veery interesting area, many papers written and no doubt many wrists slashed over this. %^]

  • Andrew 2007-09-26 01:28
    As an infrastructure architect I see what Alex is talking about all the time. My simple rule is that nothing but validation and display should be processed at the presentation (client) level. All else should either be database contraints, stored-procedures (although I'm not keen on these unless there is a damned good performance reason) or in a "middle-tier" which ideally should (or be able to) be on a separate server to the database.

    The key driving point behind this attitude is that then you can pretty much deploy an application to anyone in any place without much effort (aside from security). Bandwidth is still expensive over the long haul.

    CAPTCHA: onomatopoeia . Bang!
  • MichaelR 2007-09-26 03:08
    Fedaykin:

    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.


    (Thanks for the article Alex....)

    I don't agree with you, Fedaykin. Here's the way I think about the Business Layer:

    1. If you wanted to move a (well-written) fat client application with basic file storage to a web application with database, the business logic is the part that you can reuse _without_modification_.
    2. The business logic probably doesn't depend on any frameworks (except collections or maybe a rule engine).
    3. The business logic is the part of the application that a businessman would be able to explain how it works.
    4. The "Model" in MVC is the core of the business logic, but usually also includes persistence logic. When fetching data from the persistance layer, the result (in a proper OO implementation)

    I agree that the Controller contains some elements of business logic, but the difference is that the Controller does not "understand" what the business objects mean, and how they relate to each other. For example, it has no logic to determine when a customer might be a gold or platinum customer. If it somehow receives that information from the View, it should pass it directly on to the Model. If it then needs to make som controller-type decision based on whether the customer is platinum, then it should ask the Model for that information. (because the model might specify that e.g. email confirmation needs to take place before a customer is _really_ a platinum customer.

    The problem is that most frameworks nowadays are VC frameworks - it is up to _you_ to build the M, and to keep it seperate from both V and C (and persistance). Many frameworks we use today make it hard to do MVC separation, without a lot of extra effort.

    It's easier to think about for, say, a mathematical graphing app with no persistance. Calculating what the wavy graph will look like is the model. Calculating where the lines will go on the screen is of course the View. What the buttons do to the Model and the View is Controller logic.

    /Michael
  • W 2007-09-26 03:28
    The problem is that the database code and the validation code is written separately; it does not have to be. Code generation is an important part of larger projects that uses disparate systems. Whether it's XML, classes in an OO programming language, or relational database tables, the info set, the rules for what is allowed and not allowed, is the same, and can be encoded once and only once, then used to generate the needed create table statements, XML schemas, or classes.

    What do you do when the requirements change? Search through all the different systems with its different rules and hope you catch everywhere you need to change the rules?
  • phx 2007-09-26 03:34
    Codegen is an archaic concept thats been made obsolete by proper use of metadata, like attributes and AOP techniques.
  • Darkstar 2007-09-26 03:55
    Might have been a bit of a preach, might have been a bit on the serious side, but stuff like this has spawned so many WTFs.

    Like a previous commenter has mentioned, I've been in a situation where I had to code a system like this, horrendously complex, supposedly future proof, nightmare logic and code to carry out simple tasks (where and IF .. ELSE .. ENDIF would have done just as well), and a year down the line when the company changed one of it's core working practices the application failed them.

    Faced with the prospect of another year of major development work to get the application up and running again, the company decided to "let the developers go" and buy off the shelf products.

    I was fortunate enough to be working closely with the database manager and he saved my neck by requesting that I change departments as he needed help managing the mess.

    We still have the application and the code round here somewhere, if I could just dig it out, I could keep this site supplied with WTFs for years, lol.
  • ThomL 2007-09-26 04:46
    I think a lot of the problem is that the logical layering of a software design has been equated with the physical deployment of an application into (n-)tiers. These should be orthogonal concepts - there's no reason that (for example) a bit of your business logic layer can't run on your presentation tier.

    Layering is an essential concept in software design and has been successfully applied so that you and I can program in Java and not assembly. I would argue that a layered approach will be found in most successful software and that you can and SHOULD reduce or eliminate the need for duplication of information between these layers. Well structured error handling between layers is your friend here.

    Tiers are a deployment concept and may or may not be necessary or even possible depending on the precise requirements of your project. Let's stop confusing these two concepts.

    ThomL.

    P.S. Alex - just because one effort to reduce duplication between layers (the ERE) resulted in a huge WTF does not mean that the exact opposite (duplicate logic everywhere) is the right answer. System design is not binary ;)

  • LKM 2007-09-26 04:55
    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.


    >As demonstrated, it’s completely infeasible to encapsulate an
    >application’s business logic into a single layer. It’s also
    >logically impossible.

    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.
  • valerion 2007-09-26 05:06
    "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.
  • Miklos Hollender 2007-09-26 05:09
    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...
  • Pasi 2007-09-26 05:23
    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!
  • Clay Feet 2007-09-26 06:30
    Anonymous coward:

    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.)


    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.

  • Samuel Carlsson 2007-09-26 06:50
    Has anyone spotted the WTF in this storie yet?
  • Fr 2007-09-26 07:12
    Samuel Carlsson:
    Has anyone spotted the WTF in this storie yet?


    The use of pseudo hungarian notation in the database naming convention?
  • DZ-Jay 2007-09-26 07:53
    Wow. Just. Wow.

    >> neat! With this hammer, we can build a tool that can pound in nails.

    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.

    -dZ.
  • otto 2007-09-26 07:55
    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.
  • anon 2007-09-26 08:54
    The definition of business logic is literal and broad, making the article flawed and misleading.
  • Wardall 2007-09-26 08:59
    Thanks for article. I totaly agree with you.
  • liserdarts 2007-09-26 09:29
    Business logic [biz-nis loj-ik] (noun):
    1. The absences of any logic
    2. Nonsense
    3. When the executives introduced their newest idea, it didn’t seam right to call it logic anymore.
  • topcat_arg 2007-09-26 09:39
    CLAP CLAP CLAP (standing ovation)...

    I will print this and throw it at some call designers around here...
  • Grrr 2007-09-26 09:46
    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?
  • Mike 2007-09-26 09:58
    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.
  • JOHN 2007-09-26 10:19
    otto:
    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.


    Spoken like someone who doesn't know how to program properly.

    Go away, troll.
  • KenW 2007-09-26 10:27
    Steve:
    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.


    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.
  • clickonce 2007-09-26 10:41
    JOHN:

    As such, it is incredibly easy to put together a code factory that relies on given rules defined in the database which automatically generates javascript code for the client tier, and C# code for the business tier.

    No duplication needed. Want to change a business rule? Pop into the database, change a field, voila, done in 10 seconds.


    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.
  • Licky Lindsay 2007-09-26 10:56
    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.
  • xboob 2007-09-26 12:04
    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”.


  • Geekwad 2007-09-26 13:08
    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.
  • wbrianwhite 2007-09-26 13:20
    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.
  • Shinobu 2007-09-26 13:25
    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.
  • xboob 2007-09-26 13:47
    wbrianwhite:
    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.


    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"






  • Phat Wednesday 2007-09-26 14:02
    antonrojo:
    I always thought business logic refers to changes made in an application blah blah blah


    I always thought Business Logic was an oxymoron.
  • Jon W 2007-09-26 14:31
    "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.
  • James 2007-09-26 14:55
    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.
  • DZ-Jay 2007-09-26 15:41
    wbrianwhite:
    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....


    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.

    -dZ.
  • will 2007-09-26 16:14
    James:
    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.


    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.
  • xboob 2007-09-26 16:36
    James:
    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.


    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.

    1. db
    2. SP
    3. DAL
    4. BLL
    5. PL

    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.

  • Z 2007-09-26 16:38
    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.
  • wbrianwhite 2007-09-26 16:47
    DZ-Jay:

    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.

    -dZ.


    Who is talking about a singe instance? If you haven't seen this kind of thing before, you are a relative newcomer to development. I cannot count the number of times I have seen people writing these be all end all solutions that end up replicating all of html and all of the built in data integrity features in a relational database, and doing both poorly.

    Let's say though, that you had a decent system worked out for transforming your one common set of requirements into all three layers (almost impossible). Now - what the hell do you do when the business decides to AJAX-ify your front end? Now all your business logic must suddenly be embedded in javascript instead of being server side.

    Programming AJAX is complicated and advanced javascript specific enough as it is. Transforming some common set of requirements into that code is going to be A) next to impossible, B) make massive use of inefficient libraries, and C) take five times as long to develop.

    Program HTML in HTML or a simple server side script to generate it.
    Program CSS in CSS or a simple server side script to generate it.
    Program Javascript in Javascript directly in most cases.
    Program data integrity and size rules in DDL directly.

    If you do not, you are certain to have a harder time changing the front end than you should, and you are certain to not be using relational database tools to the most effect. Can you transform a business rule into a system of history tables and insert/update/delete triggers? Not so much.

    Please note though Alex's decrying of a lack of definition of what "business layer" means. We may not be talking about the same thing.

  • xboob 2007-09-26 16:50
    Jon W:
    "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.


    1. generate database schema (xsd - 500+ lines of nasty nested xml code)
    2. metadata (more lines of code/data)
    3. bindings (wow... these are loaded with performace issues)
    4. generate data structures

    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#.


  • Troy 2007-09-26 16:57
    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.
  • xboob 2007-09-26 17:01
    Z:
    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.


    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?
  • wbrianwhite 2007-09-26 17:59
    xboob:

    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.


    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.
  • Kuba 2007-09-26 18:00
    IceFreak2000:
    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.


    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
  • Kuba 2007-09-26 18:05
    wbrianwhite:
    DZ-Jay:

    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.

    -dZ.


    Who is talking about a singe instance? If you haven't seen this kind of thing before, you are a relative newcomer to development. I cannot count the number of times I have seen people writing these be all end all solutions that end up replicating all of html and all of the built in data integrity features in a relational database, and doing both poorly.

    Let's say though, that you had a decent system worked out for transforming your one common set of requirements into all three layers (almost impossible). Now - what the hell do you do when the business decides to AJAX-ify your front end? Now all your business logic must suddenly be embedded in javascript instead of being server side.

    Programming AJAX is complicated and advanced javascript specific enough as it is. Transforming some common set of requirements into that code is going to be A) next to impossible, B) make massive use of inefficient libraries, and C) take five times as long to develop.


    I don't know about that. Did just that, including language transformation (LISP to javascript) and it was, in fact, pretty smooth. The application was written in lisp, and automatically separated into the server-side lisp, and client-side javascript/html. It does require learning some compiler-writing-style concepts, but once you get a hang of it, it really makes life simple.

    You never have to maintain any generated code, only the code generator.

    Cheers!
  • wbrianwhite 2007-09-26 18:19
    Kuba:

    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


    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.
  • wbrianwhite 2007-09-26 18:26
    Kuba:

    I don't know about that. Did just that, including language transformation (LISP to javascript) and it was, in fact, pretty smooth. The application was written in lisp, and automatically separated into the server-side lisp, and client-side javascript/html. It does require learning some compiler-writing-style concepts, but once you get a hang of it, it really makes life simple.

    You never have to maintain any generated code, only the code generator.

    Cheers!


    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.
  • wbrianwhite 2007-09-26 18:40
    xboob:

    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.


    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.
  • Coffee Freak 2007-09-26 18:57
    Anonymous coward:
    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.


    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.
  • John Coleman 2007-09-26 19:52
    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.
  • Jay 2007-09-26 22:08
    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..
  • ActionMan 2007-09-27 01:39
    To all arrogant argumentative fuckers in here:

    READ THE FREAKING DEFINITION USED IN THE JOKE ARTICLE:
    business logic (n.) — any program code (“logic”) that pertains to the purpose (“business”) of a software application





    ...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"
  • Pasi 2007-09-27 03:13
    wbrianwhite:
    Never replicate what a database can already do.
    Never replicate what a general purpose programming language can already do.

    Simple rules I live by.

    Simple but smart. When I was working in a software company as a security manager the dev guys had a funny principle: simple programmers are the best programmers. I think they're right.

    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... "
  • tieTYT 2007-09-27 04:22
    LKM:
    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.


    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.
  • tieTYT 2007-09-27 04:25
    Grrr:

    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?
    +5 insightful
    captcha: stinky
  • tieTYT 2007-09-27 04:35
    clickonce:

    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.


    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?
  • tieTYT 2007-09-27 04:59
    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!
  • Maximilianop 2007-09-27 05:54
    The article pretty much sums all I've ever recalled from daily WTFs, but some (I won't read 144 of them) bashing comments says the article is completely wrong...

    I always thought there is a possible dual interpretation for "business logic" inside an application:
    1. What your application does for the client.
    2. How your application does it.

    I Guess Alex interprets BL as my 2nd possibility or he focus on that one. While those comments go for the 1st.

    Multiplicating the Client's BL is always a bad practice... While on the App's it's unavoidable.

    You do it by defining a field's length on the DB, later defining a field length for the user's input object in the least. You HAVE to avoid the user input being different size the constraints on the DB field are...

    Of course, there are methods to avoid MANUALLY (programmer wise) enforcing this for every input object, i.e: defining a class which evaluates DB field type (as someone already pointed) and later having each and every user input object to validate against it's class pre-evaluated constraints on each. This would avoid you from MANUALLY repeating app logic, but the app itself will be automatically repeating the "check for constraint" logic.
  • xboob 2007-09-27 10:36
    tieTYT:
    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!


    There is still no need for a business logic layer in your example.

    What you are talking about here is usualy just a brain fart of an idea and is never a request that comes from the client.

    Most of the business logic that acts on the data will be in stored procedures anyway. So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.

    Please tell me where you would place the code this request.

    Make the drop down list visible when the user enteres an account number in the textbox that starts with 999. This is client side business logic that will have to be duplicated on each form/page
  • wbrianwhite 2007-09-27 12:15
    Maximilianop:

    You do it by defining a field's length on the DB, later defining a field length for the user's input object in the least. You HAVE to avoid the user input being different size the constraints on the DB field are...

    Of course, there are methods to avoid MANUALLY (programmer wise) enforcing this for every input object, i.e: defining a class which evaluates DB field type (as someone already pointed) and later having each and every user input object to validate against it's class pre-evaluated constraints on each. This would avoid you from MANUALLY repeating app logic, but the app itself will be automatically repeating the "check for constraint" logic.


    That's a nice theory. But what if your site/app is used by multiple clients who have rules about how long an employee id is? Then the DB field needs to be at least as big as the biggest of them, and the input fields cannot at all rely on the size of that field to maxlength themselves. It is simple to slap a maxlength on a text input. It doesn't need to be tied to the size of a field in the database. This is a place where separation of layers is important. You do not need to be letting your DB determine screen layout, or vice versa.
  • Kuba 2007-09-27 13:27
    wbrianwhite:
    Kuba:

    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


    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.


    Although the application itself was tiny, and I didn't even have to implement any of the SQL tuning, it could offer as much SQL tweaking as you desired.

    The actual lisp counterparts to SQL statements that do the tining were never implemented, but it'd be trivial enough to do. If it came to that, the DBA would never have to deal with intervening in the generated SQL, he'd simply come to me for a few hours, explain his concerns, and they'd be addressed in the code generator.

    Most likely, the code generator would get extra rules to autoparallelize, deduce locking levels and whatnot. It already did quite a bit of that in javascript generation. It used what amounted to an expert system, the rules were written in lisp syntax. In fact, I've just looked again at the code and the DBA could extend the rules with knowledge about parallelization etc. He wouldn't like it, as with the rules in place he'd become redundant very quickly :)


    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.


    There was no way to hand tune anything after code generation. This would kind of make the whole thing pointless to begin with.

    You only dealt with an application written with lisp, and the rules that governed code generation. The code generator implemented an expert system that you won't see in most projects. It will be someday my next step to move some of "hardcoded" application into the expert system (right now it's only used for code generation), so that there's even less lisp to write by hand.

    This approach has the benefit that a lot of its functionality could be (with some more work) formally proven against requirements. It's not fragile at all. In fact, it offers a lot of built-in checks and there's no way to get the webpages, the middle tier and the database out of sync. It's all consistent from the get-go.

    It's not something that I'd expect a random web-developer to do. I enjoy learning, and I had to learn a lot in the process. If I were to do it in a development company somewhere, I'd be hiring a few accomplished Ph.Ds who really know about that stuff first.

    Cheers!
  • Kuba 2007-09-27 13:40
    wbrianwhite:
    Kuba:

    I don't know about that. Did just that, including language transformation (LISP to javascript) and it was, in fact, pretty smooth. The application was written in lisp, and automatically separated into the server-side lisp, and client-side javascript/html. It does require learning some compiler-writing-style concepts, but once you get a hang of it, it really makes life simple.

    You never have to maintain any generated code, only the code generator.

    Cheers!


    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.


    Well, since the whole thing is written in just one general-purpose language (lisp), you'd use mostly the same techniques you use elsewhere. The generated files, if they don't work properly, but the input (lisp) is correct, become testcases for the code generator, and end up in bug fixes for the same. What else would you expect?

    As for changing "only one instance of the thing X" you do it just as you would ordinarily do it. The webpages, forms etc. are generated by lisp code, instead of being written by hand, which ensures that they stay in sync with everything else. If you want one place where the FirstName field is truncated or displayed in pink instead of the default style, it's trivial to do so.

    I don't see why the application would collapse as it grew. I'd fully expect the opposite: as it grew, more functionality was added to the code generator and its rule logic, thus making you write incrementally less code for features of given complexity, as the application grew.

    In fact, in its beginnings the code was a real mess. As it grew things stabilized, as I saw where one can refactor programmer-written code into generated code, and so on.

    If I find some time (unlikely this quarter as I'm taking a pretty demanding scientific computing class in addition to a side project), I could think about implementing the functionality of dailywtf.com site (including bulletin board, article management, etc), and setting it up somewhere for people to try out and see how the code looks and works. It'd be in scope of what the code generator already handles. I'm half-expecting the whole thing to be less than 3000 lines of lisp.

    Cheers, Kuba
  • Kuba 2007-09-27 13:44
    wbrianwhite:
    xboob:

    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.


    Never replicate what a database can already do.
    Never replicate what a general purpose programming language can already do.


    I'd never think of replicating what a database can do. In the similar vein, lisp is a very general purpose programming language. That's the main benefit of it: it's more expressive than javascript, and the fact that you generate SQL from lisp just means that you code using a common syntax and some common semantic conventions for the whole thing. And that you get rid of a slew of human-induced problems.

    Cheers, Kuba
  • Tei 2007-09-27 13:45
    game developers use a scripting languaje to make the separation the game logic, and the core of the application (the engine).

  • Bernie Quick 2007-09-27 13:54
    Never before have I left a comment. Never before have I seen someone prove over and over again what an idiot that are!
  • tieTYT 2007-09-27 13:56
    xboob:

    Most of the business logic that acts on the data will be in stored procedures anyway.


    Uh, obviously you don't realize this, but there is a religious debate about this issue. It's not a fact that stored procedures are good. One obvious downside is that using them usually makes it extra difficult to use a different data source. Second, they're rarely (if ever) object oriented. I think stored proc's are a hammer like everything else.

    So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.
    Listen, to get the benefit out of MVC, you need to understand why you'd use it. It all depends on the assumption that the model stays relatively constant while the view is constantly changing or even being completely replaced. As such, whether you put this code in the business layer or the persistence layer, you're still getting major benefits than putting it in the presentation layer. That's whats important.
  • xboob 2007-09-27 14:25
    tieTYT:
    xboob:

    Most of the business logic that acts on the data will be in stored procedures anyway.


    Uh, obviously you don't realize this, but there is a religious debate about this issue. It's not a fact that stored procedures are good. One obvious downside is that using them usually makes it extra difficult to use a different data source. Second, they're rarely (if ever) object oriented. I think stored proc's are a hammer like everything else.

    So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.
    Listen, to get the benefit out of MVC, you need to understand why you'd use it. It all depends on the assumption that the model stays relatively constant while the view is constantly changing or even being completely replaced. As such, whether you put this code in the business layer or the persistence layer, you're still getting major benefits than putting it in the presentation layer. That's whats important.


    The downside that you quoted is not an issue. 99% of the time the database technology won't change and there will be only one (SQL Server, Oracle, MySQL, etc).

    Far to many programmers fail to stay within scope of the project. If the program doesn't require more then one database technology then why develop for that? Why waste your time and your customers money on somthing that might never happen?

    The business logic should be where it fits best. Sometimes you have no option but to put it in the PL. Creating an extra layer for the business logic is extra work and a duplication of effort.

  • Geekwad 2007-09-27 16:04
    xboob:

    The downside that you quoted is not an issue. 99% of the time the database technology won't change and there will be only one (SQL Server, Oracle, MySQL, etc).


    This may be true in your segment, but I find that databases are a retardedly political topic. I have been asked to change database back ends many times for completely non-technical reasons. One client gets into a licensing tiff with Oracle. Another reads an article that says that SQLite is faster than pgsql and can't be convinced that it doesn't bloody matter. Another client goes out to drinks with a distributor and makes a dumb decision I have to work around. And on and on.

    I don't know why this is. I have clients who raise a fuss if they get a proposal that does not somewhere within it contain the magic letters, "SQL". It doesn't matter if it is a web proxy or a screen saver, it needs to use SQL or it isn't following his "best practices".

    I think it's just due to the huge amount of money in databases. People with cheque-writing ability but no technical background get fed FUD and other ghost stories that scare them into making decisions they should be delegating. This is probably also the reason that it's so darn hard to migrate between back ends. There's a financial incentive to keep migration hard and discourage interoperability.
  • wbrianwhite 2007-09-27 16:36
    Kuba:

    Although the application itself was tiny, and I didn't even have to implement any of the SQL tuning, it could offer as much SQL tweaking as you desired.

    The actual lisp counterparts to SQL statements that do the tining were never implemented, but it'd be trivial enough to do. If it came to that, the DBA would never have to deal with intervening in the generated SQL, he'd simply come to me for a few hours, explain his concerns, and they'd be addressed in the code generator.

    Most likely, the code generator would get extra rules to autoparallelize, deduce locking levels and whatnot. It already did quite a bit of that in javascript generation. It used what amounted to an expert system, the rules were written in lisp syntax. In fact, I've just looked again at the code and the DBA could extend the rules with knowledge about parallelization etc. He wouldn't like it, as with the rules in place he'd become redundant very quickly :)


    What arrogance :) The DBA - who is the only one who can trace the actual performance, and who will still apparently have the right to go in and add indexes and whatnot, will have to come to you when there's one particular query that needs a max degree of parallelism query hint added, and you will have to then find how this query is generated, separate it from the other similar queries into a new class (because the query hint would be counterproductive for those other) and then regenerate it. By way, you are 110% WRONG if you think you can predict ahead of time which queries need which options. You can only find out what's needed by a trace of your production system running under normal load and analyzing performance. Optimization can almost never be done ahead of time, you need to analyze the actual bottlenecks in your system and improve them once it's already running. Otherwise you spend your time on things that take a long time and offer little benefit.

    The DBA would be redundant? Grow up. You're not smarter than everyone else. DBAs are better than developers at database performance tuning. It's their job.

    And you think this approach is productive? It will take a minimum of hours by your own admission for this one simple task. Adding that one line to the one query and checking it into source control would take 10 minutes top.

    Kuba:

    This approach has the benefit that a lot of its functionality could be (with some more work) formally proven against requirements. It's not fragile at all. In fact, it offers a lot of built-in checks and there's no way to get the webpages, the middle tier and the database out of sync. It's all consistent from the get-go.


    That's fine.... until you get a requirement that the front end field be smaller than the db field.

    Kuba:

    It's not something that I'd expect a random web-developer to do. I enjoy learning, and I had to learn a lot in the process. If I were to do it in a development company somewhere, I'd be hiring a few accomplished Ph.Ds who really know about that stuff first.

    Cheers!


    My apologies. You do think you're smarter than everyone else. Why would computer science Ph.Ds be doing web development work? And why do you assume they'd be good at it? There are many platforms that already exist for making web applications. You're not going to make a better platform on the side while focusing primarily on your application.
  • wbrianwhite 2007-09-27 16:49
    Geekwad:
    xboob:

    The downside that you quoted is not an issue. 99% of the time the database technology won't change and there will be only one (SQL Server, Oracle, MySQL, etc).


    This may be true in your segment, but I find that databases are a retardedly political topic. I have been asked to change database back ends many times for completely non-technical reasons. One client gets into a licensing tiff with Oracle. Another reads an article that says that SQLite is faster than pgsql and can't be convinced that it doesn't bloody matter. Another client goes out to drinks with a distributor and makes a dumb decision I have to work around. And on and on.

    I don't know why this is. I have clients who raise a fuss if they get a proposal that does not somewhere within it contain the magic letters, "SQL". It doesn't matter if it is a web proxy or a screen saver, it needs to use SQL or it isn't following his "best practices".

    I think it's just due to the huge amount of money in databases. People with cheque-writing ability but no technical background get fed FUD and other ghost stories that scare them into making decisions they should be delegating. This is probably also the reason that it's so darn hard to migrate between back ends. There's a financial incentive to keep migration hard and discourage interoperability.


    I don't know what line of work you're in. I've worked at 5 companies over about 9 years. I've never personally seen anyone change their DB server. Before I got here, the company I'm at did have a product they acquired that ran on Oracle that they moved to SQL Server because of a licensing issue with Oracle - per server versus per processor or some nonsense like that. That's it.
  • wbrianwhite 2007-09-27 17:01
    Kuba:

    If I find some time (unlikely this quarter as I'm taking a pretty demanding scientific computing class in addition to a side project), I could think about implementing the functionality of dailywtf.com site (including bulletin board, article management, etc), and setting it up somewhere for people to try out and see how the code looks and works. It'd be in scope of what the code generator already handles. I'm half-expecting the whole thing to be less than 3000 lines of lisp.

    Cheers, Kuba


    Ah. You're a college student, so you have no real life experience maintaining something. Got it. You are bound and determined to learn the hard way.

    That site you're proposing there is a waste of time. I could implement a content management system like DotNetNuke in a couple of days, and the ASP based Snitz forums in 2 days. These things are already written platforms, maintained by dozens of developers who find all the flaws, and fix them.
  • Fred768 2007-09-27 17:36
    Is this article trolling to wind us all up? It's trashing the proven-and-heavily-used MVC (Model-View-Controller) design pattern. The basic idea being to separate the application into three layers, which may be replaced separately. Encapsulation is an absolutely key point of programming maintainable, stable and testable code.

    The author seems to be confusing integrity constraints and mere UI decoration with *actual* business logic. The UI can ensure that the user enters valid data into it, before it's passed down to the business logic to be processed. The persistence layer can ensure that the data remains stored in a consistent manner, and pick up on any errors within the business logic. Obviously, it's possible to write a subsystem which all three layers can use to determine (for example) data type, but this will, as always depend on the size and complexity of the application.

    The suggestion that the programmer should search and replace throughout the code is truly insane. Various languages contain features from simple macros to generics in order to avoid this kind of work, seeing as it results in 'code rot', and replicated code, which in turn results in longer more complex code with more paths and thus more cases to test.

    Even Joel has written an article somewhere about 'lazy' programmers who write frameworks to avoid code replication being the best programmers.

    Over-engineering code is bad, but under-engineering it is often even worse.
  • Corporate Cog 2007-09-27 17:53
    A bunch of people agree, a bunch don't. It seems safe to conclude that there's no *right* or *better* way. Whatever works for you is the way to do it. Probably proves true for half the wtfs posted to this site.
  • tieTYT 2007-09-27 18:16
    Corporate Cog:
    A bunch of people agree, a bunch don't. It seems safe to conclude that there's no *right* or *better* way. Whatever works for you is the way to do it. Probably proves true for half the wtfs posted to this site.
    or that there are ignorant people and experienced people and they're arguing.
  • FlorisDenHeijer 2007-09-27 20:37
    Kuba:
    If I find some time (unlikely this quarter as I'm taking a pretty demanding scientific computing class in addition to a side project), I could think about implementing the functionality of dailywtf.com site (including bulletin board, article management, etc), and setting it up somewhere for people to try out and see how the code looks and works. It'd be in scope of what the code generator already handles. I'm half-expecting the whole thing to be less than 3000 lines of lisp.


    5$ the thing you'll end up with is not what you described.
  • titie 2007-09-28 01:01
    all this talk about MVC makes me think that some people here don't even know what it is.

    MVC doesn't have a business logic layer.

    Take for example a website created using CodeIgniter. Don't look at asp.net because it isn't MVC . The Code behind doesn't give you MVC.

    MVC says nothing about the business layer. It is a structure for modular systems. The controler controls program structure, the Model is the modual, and the view is the interface.

    MVC doesn't have for example file called BLL.DLL that contains all the business logic. There can still be business logic in the tables, stored procedures, controlers, models and views (javascript).



  • Simmo 2007-09-28 01:38
    kindall:
    Column names in your database are not business logic (anything having to do with the database is, by definition, persistence tier).

    Of course they are business logic - otherwise, to paraphrase, you might as well call them column01, column2 etc.

    kindall:
    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.

    And how exactly does it do that, poopy-pants? By using business rules, of course. You're not telling me that the rule 'if it's past due, display it in red' is not a business rule, surely?

    kindall:
    ... 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.

    Alex is simply pointing out that we often spend far too much time just on maintaining these differences, and it might actually be more cost-effective sometimes to allow these rigidly defined areas be a bit more relaxed.
  • Simmo 2007-09-28 01:43
    titie:
    all this talk about MVC makes me think that some people here don't even know what it is.

    MVC doesn't have a business logic layer.

    Take for example a website created using CodeIgniter. Don't look at asp.net because it isn't MVC . The Code behind doesn't give you MVC.

    MVC says nothing about the business layer. It is a structure for modular systems. The controler controls program structure, the Model is the modual, and the view is the interface.

    MVC doesn't have for example file called BLL.DLL that contains all the business logic. There can still be business logic in the tables, stored procedures, controlers, models and views (javascript).





    This is the most enlightened comment in this whole damn list if you ask me
  • ActionMan 2007-09-28 02:36
    You people are still arguing while using a different definition than the joke uses....

    business logic (n.) — any program code (“logic”) that pertains to the purpose (“business”) of a software application





    Everyone's a smarty pants when they change the very definition of what is being discussed...
  • Fred768 2007-09-28 02:37
    If you're going to divide up the application into presentation, business and persistence, as stated in the article, then you are basically implementing the MVC design pattern. Although, as you say it's very possible to deviate from that, the controller part of the application should generally contain the absolute bulk of the business logic, with as little as possible elsewhere. Integrity constraints within the database and UI shouldn't, for example directly relate to user permissions.
  • ActionMan 2007-09-28 02:43
    Fred768:
    If you're going to divide up the application into presentation, business and persistence, as stated in the article, then you are basically implementing the MVC design pattern. Although, as you say it's very possible to deviate from that, the controller part of the application should generally contain the absolute bulk of the business logic, with as little as possible elsewhere. Integrity constraints within the database and UI shouldn't, for example directly relate to user permissions.

    And as pointed out above, the V in MVC often contains business rules, such as "items marked with this flag should be displayed using the color #FF0000" (i.e. a business rule pertaining to the presentation of a report...)
    Hence trying to isolate all of this BL into just the C part is going to lead to an over-engineered solution.
  • Terry N 2007-09-28 09:45
    Layering is bad. TCP/IP has been a disaster so far - completely unworkable - layered architectures will never catch on.
  • wbrianwhite 2007-09-28 11:08
    Terry N:
    Layering is bad. TCP/IP has been a disaster so far - completely unworkable - layered architectures will never catch on.


    Maybe, just possibly, network protocols are not the same thing as development methodologies?
  • titie 2007-09-28 11:14
    Fred768:
    If you're going to divide up the application into presentation, business and persistence, as stated in the article, then you are basically implementing the MVC design pattern. Although, as you say it's very possible to deviate from that, the controller part of the application should generally contain the absolute bulk of the business logic, with as little as possible elsewhere. Integrity constraints within the database and UI shouldn't, for example directly relate to user permissions.


    umm.. no. the controller controls program flow. For example, if I request the CustomerContactList from the customer controller it should call a funtion in the customer module and then pass the results to the view. Most of the business logic will be in the Customer Module not the controller. The controller is the glue between the interface and the module. The the controller is not the business logic layer. The relationship between M,V, and C is a triangle it not a stacked layer.
  • Zygo 2007-09-28 15:02
    wbrianwhite:
    Kuba:

    Although the application itself was tiny, and I didn't even have to implement any of the SQL tuning, it could offer as much SQL tweaking as you desired.

    The actual lisp counterparts to SQL statements that do the tining were never implemented, but it'd be trivial enough to do. If it came to that, the DBA would never have to deal with intervening in the generated SQL, he'd simply come to me for a few hours, explain his concerns, and they'd be addressed in the code generator.

    Most likely, the code generator would get extra rules to autoparallelize, deduce locking levels and whatnot. It already did quite a bit of that in javascript generation. It used what amounted to an expert system, the rules were written in lisp syntax. In fact, I've just looked again at the code and the DBA could extend the rules with knowledge about parallelization etc. He wouldn't like it, as with the rules in place he'd become redundant very quickly :)


    What arrogance :) The DBA - who is the only one who can trace the actual performance, and who will still apparently have the right to go in and add indexes and whatnot, will have to come to you when there's one particular query that needs a max degree of parallelism query hint added, and you will have to then find how this query is generated, separate it from the other similar queries into a new class (because the query hint would be counterproductive for those other) and then regenerate it. By way, you are 110% WRONG if you think you can predict ahead of time which queries need which options. You can only find out what's needed by a trace of your production system running under normal load and analyzing performance. Optimization can almost never be done ahead of time, you need to analyze the actual bottlenecks in your system and improve them once it's already running. Otherwise you spend your time on things that take a long time and offer little benefit.


    I second wbrianwhite's comment.

    SQL implementations have *lots* of automatic query optimization capability already, and these optimizers have access to data that your application's code does not, especially at compile time (e.g. the database knows about the statistical distribution of data in the database, total size of the data, data processing capacity of the server, runtime costs of various algorithms on various data distributions, etc, and can make optimization decisions based on this information at runtime). Generally you want to write a query that is simple and straightforward and gives the SQL runtime lots of alternative ways to implement it, and let the SQL runtime do the rest of the work for you.

    That works 99% of the time. After all, 99% of the time your query looks like 'SELECT * FROM foo NATURAL JOIN bar WHERE order_id = $1' and it is implemented using two index lookups.

    The other 1% of the time, you have to test a number of ways to write the query and pick the one that works best. 1% of the time when you need to do that, it doesn't work so you need to denormalize the schema, or even go all the way back to the requirements level and change the data model or (in extreme cases) the process flow.

    One huge problem with the Kuba approach is that it's easy to generate a data schema from scratch, but not so easy to impose a new data schema on an existing production database with some data in it. I'm still writing database schema update scripts manually, because the automated tools I've seen choke and die before they figure out how to make arbitrary schema changes without tripping over existing data constraints. I suppose one way around this is to have the code generator make a serializer and a deserializer for the old and new schema respectively, and dump the old database into a new one...but that doesn't work so well when your database occupies 90% of the biggest disk array you can afford, or if you can't afford the hours of downtime during the translation.
  • ET 2007-09-28 17:57
    Congratulations... you've taken something I agree with and turned it into a self-righteous monologue on why your opinion is the truth.

    You have created a soapbox from which you have the opportunity to preach your own brand of reality. That doesn't mean you should, or that you are somehow as interesting as the articles you post for us to laugh at (which require no creativity on your part... your descriptions are not the highlight of this site).

    I read this site for amusement, not for your little diatribes. I have my own website to post those on; perhaps you should keep your opinions where they belong, in a blog of some sort.
  • wbrianwhite 2007-09-28 18:03
    Zygo:

    I'm still writing database schema update scripts manually, because the automated tools I've seen choke and die before they figure out how to make arbitrary schema changes without tripping over existing data constraints. I suppose one way around this is to have the code generator make a serializer and a deserializer for the old and new schema respectively, and dump the old database into a new one...but that doesn't work so well when your database occupies 90% of the biggest disk array you can afford, or if you can't afford the hours of downtime during the translation.


    I would recommend that your DDL also be in source control. The company I'm at now is actually the first place I've seen a mandatory inclusion of all DDL in source control. Good god does it make life easier.

    I'm afraid the "we're going to be down for hours whenever we have a data model change" approach wouldn't fly anywhere I've worked. Not sure how well it would work with 200 gig databases either :)
  • real_aardvark 2007-09-28 18:46
    ET:
    Congratulations... you've taken something I agree with and turned it into a self-righteous monologue on why your opinion is the truth.

    You have created a soapbox from which you have the opportunity to preach your own brand of reality. That doesn't mean you should, or that you are somehow as interesting as the articles you post for us to laugh at (which require no creativity on your part... your descriptions are not the highlight of this site).

    I read this site for amusement, not for your little diatribes. I have my own website to post those on; perhaps you should keep your opinions where they belong, in a blog of some sort.

    Darn Tootin'! Alex should find his own website to post these on ...

    ... oh, wait.
  • real_aardvark 2007-09-28 19:08
    Simmo:
    titie:
    all this talk about MVC makes me think that some people here don't even know what it is.

    MVC doesn't have a business logic layer.

    Take for example a website created using CodeIgniter. Don't look at asp.net because it isn't MVC . The Code behind doesn't give you MVC.

    MVC says nothing about the business layer. It is a structure for modular systems. The controler controls program structure, the Model is the modual, and the view is the interface.

    MVC doesn't have for example file called BLL.DLL that contains all the business logic. There can still be business logic in the tables, stored procedures, controlers, models and views (javascript).





    This is the most enlightened comment in this whole damn list if you ask me

    Too many straw men to be properly enlightened, if you ask me. Nobody, to my memory, has proposed a commutative relationship between MVC and a "business model" type of system. They've merely suggested that the second might reasonably be implemented in terms of the first. And, although somebody did jokingly bring up a "BLL.dll," (beautiful. I'm going to propose this to my boss) I don't believe that this was held to be an absolute requirement.

    There should never be business logic, as reasonably understood, in database tables. (I don't consider "this column stores surnames" to be business logic.)

    The question of holding business logic in views (javascript) is contentious. Me, I err on the Nancy Reagan side of this argument. You might want to pursue further enlightenment through Terence Parr (Mr Antlr)'s excellent article on the subject: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

    It is not clear to me that a controller can ever hold business logic of any sort under any circumstance, other than "Oops! Fuck up! I'm outta here!"

    As for stored procedures, these plainly implement business logic to a great degree. They would do, wouldn't they? After all, they're code.

    They aren't necessarily a great solution, though, precisely because they're code and therefore suffer the usual impedance mismatch against the descriptive/set-functional (I use the term loosely) nature of SQL proper. Let's not forget that the original purpose of stored procedures was to Make Ellison Rich, and to a large extent that is still their main function.

    My main beef against excessive use (read, "implementation of business logic") of stored procedures is, quite simply, that they implicitly extend the DDL without adding any obvious benefit. There's an argument upstream about whether companies ever change database vendors or not. I would go further. Companies most certainly change database schemas, and if you tie your business logic into your schema via a wodge of stored procedures, you're just causing your maintenance programmers a lot of unnecessary agony. Sure, they could have been written in a flexible way in the first place. My experience is that they rarely, if ever, are.

    (And obviously the same problem could crop up with an external, simple, CRUD interface. As stated so often on this site, a bad programmer can write bad programs in any language.)

    IMO, stored procedures should be used as a "thin client" layer to ease the pain of persisting data (eg by creating views on the fly); never as business logic. Unless the application is simple enough that writing a full-blown MVC in the middle is overkill.
  • Benjamin Smith 2007-09-29 02:09
    clickonce:
    JOHN:

    As such, it is incredibly easy to put together a code factory that relies on given rules defined in the database which automatically generates javascript code for the client tier, and C# code for the business tier.

    No duplication needed. Want to change a business rule? Pop into the database, change a field, voila, done in 10 seconds.


    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.


    Funny, that. Developing a fairly large (~250,000 line of code) database-driven app in PHP, (that's 250,000 lines WITHOUT any HTML) I've found some surprising boosts in productivity by unifying my logic directly on the schema.

    For example, functions that will list any table and field that contain any values that reference a particular record in a table you specify, for example. This makes it almost trivial to write a "Why can't I delete this !@#@ thing" report very simple == dramatic improvement in usability. Now, we're working on a way to hook this into our error handler for our database abstraction, so that anytime a database error occurs during a delete, a clean, explanatory message is displayed.

    Wahoo!

    So, why not constrain an input? EG:

    table users
    lastname varchar(40)

    magically turns into

    <INPUT TYPE=TEXT NAME="lastname" SIZE=40 MAXLENGTH=40>

    At the very worst, you reduce the number of potential error conditions, and reduce the requirement that your coders be perfect automatons...
  • titie 2007-09-29 02:18
    real_aardvark:
    Simmo:
    titie:
    all this talk about MVC makes me think that some people here don't even know what it is.

    MVC doesn't have a business logic layer.

    Take for example a website created using CodeIgniter. Don't look at asp.net because it isn't MVC . The Code behind doesn't give you MVC.

    MVC says nothing about the business layer. It is a structure for modular systems. The controler controls program structure, the Model is the modual, and the view is the interface.

    MVC doesn't have for example file called BLL.DLL that contains all the business logic. There can still be business logic in the tables, stored procedures, controlers, models and views (javascript).





    This is the most enlightened comment in this whole damn list if you ask me

    Too many straw men to be properly enlightened, if you ask me. Nobody, to my memory, has proposed a commutative relationship between MVC and a "business model" type of system. They've merely suggested that the second might reasonably be implemented in terms of the first. And, although somebody did jokingly bring up a "BLL.dll," (beautiful. I'm going to propose this to my boss) I don't believe that this was held to be an absolute requirement.

    There should never be business logic, as reasonably understood, in database tables. (I don't consider "this column stores surnames" to be business logic.)

    The question of holding business logic in views (javascript) is contentious. Me, I err on the Nancy Reagan side of this argument. You might want to pursue further enlightenment through Terence Parr (Mr Antlr)'s excellent article on the subject: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

    It is not clear to me that a controller can ever hold business logic of any sort under any circumstance, other than "Oops! Fuck up! I'm outta here!"

    As for stored procedures, these plainly implement business logic to a great degree. They would do, wouldn't they? After all, they're code.

    They aren't necessarily a great solution, though, precisely because they're code and therefore suffer the usual impedance mismatch against the descriptive/set-functional (I use the term loosely) nature of SQL proper. Let's not forget that the original purpose of stored procedures was to Make Ellison Rich, and to a large extent that is still their main function.

    My main beef against excessive use (read, "implementation of business logic") of stored procedures is, quite simply, that they implicitly extend the DDL without adding any obvious benefit. There's an argument upstream about whether companies ever change database vendors or not. I would go further. Companies most certainly change database schemas, and if you tie your business logic into your schema via a wodge of stored procedures, you're just causing your maintenance programmers a lot of unnecessary agony. Sure, they could have been written in a flexible way in the first place. My experience is that they rarely, if ever, are.

    (And obviously the same problem could crop up with an external, simple, CRUD interface. As stated so often on this site, a bad programmer can write bad programs in any language.)

    IMO, stored procedures should be used as a "thin client" layer to ease the pain of persisting data (eg by creating views on the fly); never as business logic. Unless the application is simple enough that writing a full-blown MVC in the middle is overkill.


    Business logic should be were it fits best! why is that so complex for people here to understand?

    Case 1: BL in the DB and SPs

    Take for example a leasing system that has to calculate different taxes for 1000s of equipment on lease. Each item on lease could be in a different province/state. In this case there will be different tax calculations for each item.
    In this example the best solution is to create a table that contains all the different tax rates for each province/state, some views, and a few stored procedures that generate daily invoice runs.

    Calculating taxes is perhaps the best example of why some BL should be in the database. In fact, recently in Canada they lowered the gst and I was very happy that i had placed all my tax calculations/ invoice generation code in the database. It was simply a SQL server Job that was run every day. I only had to make one update to the db and i was done. Everything worked and I didn't have to open Visual Studio once.

    In my experience people who avoid placing BL in the database just suck at databases and Transact SQL.

    Case 2: BL in the controller

    For the controller having business logic here is a good example.

    If user X is a Sales Rep then they should see the Sales Rep Customer Form. The Controller gathers all the data it needs for the View(the form) from the Module by calling the GetCustomerForSalesReps function. In this case the data requirements and the presentation layer is different for sales reps.

    Case 3: BL in the View
    If the user X is a sales rep and he owns the customer then allow him to modify the Sales Rep notes field. In this case the View will have an if statement that enables/disables the notes field. That if statement is business logic in the presentation layer.

    Now if you don't think that these cases are valid then perhaps you should explain how you would handle them in your almighty BLL.DLL.















  • titie 2007-09-29 02:26
    Benjamin Smith:
    clickonce:
    JOHN:

    As such, it is incredibly easy to put together a code factory that relies on given rules defined in the database which automatically generates javascript code for the client tier, and C# code for the business tier.

    No duplication needed. Want to change a business rule? Pop into the database, change a field, voila, done in 10 seconds.


    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.


    Funny, that. Developing a fairly large (~250,000 line of code) database-driven app in PHP, (that's 250,000 lines WITHOUT any HTML) I've found some surprising boosts in productivity by unifying my logic directly on the schema.

    For example, functions that will list any table and field that contain any values that reference a particular record in a table you specify, for example. This makes it almost trivial to write a "Why can't I delete this !@#@ thing" report very simple == dramatic improvement in usability. Now, we're working on a way to hook this into our error handler for our database abstraction, so that anytime a database error occurs during a delete, a clean, explanatory message is displayed.

    Wahoo!

    So, why not constrain an input? EG:

    table users
    lastname varchar(40)

    magically turns into

    <INPUT TYPE=TEXT NAME="lastname" SIZE=40 MAXLENGTH=40>

    At the very worst, you reduce the number of potential error conditions, and reduce the requirement that your coders be perfect automatons...



    This is exactly the way a good programmer thinks.

    I have also done this in my applications. I even wrote a stored procedure to search all my other stored procedures and database objecta. If I want to find all the objects that make a reference to the CUSTOMER table then i just call that utility function.

  • real_aardvark 2007-09-29 11:12
    titie:

    Business logic should be were it fits best! why is that so complex for people here to understand?

    I don't think anybody on this site, including the plainly delusional ones, is finding it difficult to understand that "Business logic should be where it fits best!"

    The complexity lies in deciding where "best" might be. To summarise (probably unfairly) the previous hundred-and-god-knows posts:

    (1) Depends on the problem.
    (2) Depends on the size of the problem.
    (3) Depends on the tools used to tackle the problem.
    (4) Depends on the culture of the organisation tackling the problem.
    (5) Depends on the culture of the programmer tackling the problem.

    Life is, fortunately, not monochromatic, and both hammers and nails come in all shapes and sizes.
    titie:

    Case 1: BL in the DB and SPs

    Take for example a leasing system that has to calculate different taxes for 1000s of equipment on lease. Each item on lease could be in a different province/state. In this case there will be different tax calculations for each item.
    In this example the best solution is to create a table that contains all the different tax rates for each province/state, some views, and a few stored procedures that generate daily invoice runs.

    Calculating taxes is perhaps the best example of why some BL should be in the database. In fact, recently in Canada they lowered the gst and I was very happy that i had placed all my tax calculations/ invoice generation code in the database. It was simply a SQL server Job that was run every day. I only had to make one update to the db and i was done. Everything worked and I didn't have to open Visual Studio once.

    In my experience people who avoid placing BL in the database just suck at databases and Transact SQL.

    Whereas, of course, in my experience, people who avoid placing BL in Java/C++/C#/PHP/VB6 just suck at Java/C++/C#/PHP/VB6.

    Not true, but equivalently cretinous.

    This is another straw man. The rationale behind the choice of DB/dll/whatever is a design decision. I had rather hoped that I had made a reasonable argument for this view. The choice of implementation is <see (1,5] above>, and is far less important.

    Obviously (although not qualified by the pronoun, and therefore apparently general and mandated by the immutable laws of Physics) this is your best solution. I don't actually know what my best solution would be. It might even be a stored procedure, if it's simple enough. (Boundaries are to be blurred where convenience supercedes.) However, it's still bleedin' code, innit? Stored procedure or external CRUD; what's the important difference?

    I'll tell you what: maintenance. Refer to my original post, please. And while you're there, please note that I specifically pointed out that there is no reason to throw in extra layers if (to take your example) all you are required to do is to chuck out a report every now and again. I mean, Jesus. Obviously you'd write the thing as a stored procedure in that case. The utility, or otherwise, of a "business logic layer" is only apparent when dealing with real business problems, not some honking DBA whore getting off on making management happy with a paper-wasting report to be filed under "round: metal."

    As an excursion: what, exactly, do you mean by "Calculating taxes is perhaps the best example of this?"

    Do you have a strange yearning to re-qualify as an accountant, just so you can meet all the babes in the taxation data-entry department and impress them with the size of your TSQL stored procedures? ("It's stored now, sweetie, but only for you. And it's huge!")

    And yes, I do suck at PL/SQL. So point (5) above leads me to do the job with another tool, all other things being equal. However, and if you re-read my post, the point is that it is still a coding task.
    titie:

    Case 2: BL in the controller

    For the controller having business logic here is a good example.

    If user X is a Sales Rep then they should see the Sales Rep Customer Form. The Controller gathers all the data it needs for the View(the form) from the Module by calling the GetCustomerForSalesReps function. In this case the data requirements and the presentation layer is different for sales reps.

    You may see this as a good example. I don't. It's your choice, and you're welcome to it, but ... ummm ... hang on a minute, I'm going to change my line of argument here. "In this case the data requirements and the presentation layer (are) different for sales reps?"

    Indeed.

    Here we are focused on the responibilities of the Presentation layer. (Granted that one exists on the MVC style of model.)

    There are obviously many ways to implement the controller's side of this contract. May I humbly suggest

    template <typename DATA, typename REQUESTER>
    DATA
    GetCustomerData (REQUESTER& r) { /* Business logic */}

    I think you're talking about two different branches of business logic, not two different branches of controller logic. (And the language doesn't matter: pretty much any modern language outside of the database can cope with this.)

    I could be wrong, but it looks to me as though you're a little too comfortable with the stored procedure route, and haven't really thought out the requirements and design.
    titie:

    Case 3: BL in the View
    If the user X is a sales rep and he owns the customer then allow him to modify the Sales Rep notes field. In this case the View will have an if statement that enables/disables the notes field. That if statement is business logic in the presentation layer.

    "Owns" the customer? As in "owns the bitch?" But, joking aside.

    Not at all, that if statement is propagated to the presentation layer by the business layer. (See Terrence Parr, below, yet again.) In effect, the model^H^H^H^H^H business layer OWNS^H^H^H^H the presentation layer.

    The presentation layer has enough to do, particularly with a crap technology like web browsers. It has HTML parsing, CSS, and God knows what else to do. (Including javascript for client-side input validation, by the way. Nothing wrong with that. You still need the business logic to do server-side validation, however, so it might as well pump out the javascript for client-side validation, manifest constants and all.)

    As a reasonable (but not exclusive) design decision, "why is that so complex for <titie> here to understand?"
    titie:

    Now if you don't think that these cases are valid then perhaps you should explain how you would handle them in your almighty BLL.DLL.

    OK.

    Not my almighty BLL.DLL, by the way. As I noted, but you did not, "BLL.DLL" is a (successful) attempt at humour. I thought that, after the furore over the Lumberjack Song, Canadians had finally got over their aversion to that particular trope, but apparently there are still one or two outliers who refuse to take the occasional comment lightly whilst discussing serious matters.

    And, agree with me or not (for some reason, I'm guessing "not"), you really should read Terrence Parr's MVC thing. You can build things your way, I can build things my way, but Parr's article is a truly excellent example of why thinking about Computer Science still matters and will improve us both.

    BUSINESS LOGIC SHOULD BE SEPARATED FROM PRESENTATION LOGIC AND FROM PERSISTENCE LOGIC WHEREVER POSSIBLE.

    Or, as ol' Albie put it,
    "Make everything as simple as possible, but not simpler"

    I think that's the crux of the matter.

    Thanks, Alex. 160-odd posters can't be wrong. Delusion, however, is another matter.

    Off topic: about fifty or so posts ago, some twit came out with the comment "This is why those who can, do. Those who can't, teach."

    Well, that's Edgar Dijkstra and Niklaus Wirth properly told off, then.

    As one descended from a long line of teachers (well, three of them), may I point out that this (un)truism should properly read:

    Those who administrate teachers should not pick dingbat subjects like "Management science" and should not pick ingratiating and incompetent whores to teach those subjects.

    Less pithy. More relevant.
  • MichaelR 2007-09-29 11:49
    xboob:


    There is still no need for a business logic layer in your example.

    What you are talking about here is usualy just a brain fart of an idea and is never a request that comes from the client.

    Most of the business logic that acts on the data will be in stored procedures anyway. So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.

    Please tell me where you would place the code this request.

    Make the drop down list visible when the user enteres an account number in the textbox that starts with 999. This is client side business logic that will have to be duplicated on each form/page


    A fantastic example of how _not_ to do it, that is copied by too many developers the world over.

    To deal with your last example: the characters 999 represent something for the business, e.g. a gold customer account prefix. This is knowledge that should be kept centrally in the business logic. Your GUI should fetch this information from the business logic. So, if you were implementing in javascript with jsp, something like (I'm no jsp expert):
    if(accountNumber.startsWith('<% PremiumAccountBusinessObject.getAccountNumberPrefix() %>'){
    doWhatever();
    }

    Imagine for a moment that the customer got your solution, and later that month they merged with another company, which uses 222 as the prefix. Or they have different prefixes for each country, and you need to get the prefixes from a database.

    My example may be of limited use, but there are hundreds of things just like that in a large application. Hardcoding business information in GUIs makes the application extremely rigid and brittle. Having central business logic is the only way to make a maintainable, reuseable application that will stand the test of time.

    The customer almost never requests that you write quality, maintainable code, but that doesn't mean you should write rubbish code on purpose.

    xboob:
    just a brain fart


    A great example of the fact that "one mocks what one does not understand".

    /Michael
  • Mike 2007-09-29 14:02
    What a disappointment. To read all that rubbish only to find there is no demonstratable conclusion. WTF?!?
  • xboob 2007-09-29 15:52
    MichaelR:
    xboob:


    There is still no need for a business logic layer in your example.

    What you are talking about here is usualy just a brain fart of an idea and is never a request that comes from the client.

    Most of the business logic that acts on the data will be in stored procedures anyway. So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.

    Please tell me where you would place the code this request.

    Make the drop down list visible when the user enteres an account number in the textbox that starts with 999. This is client side business logic that will have to be duplicated on each form/page


    A fantastic example of how _not_ to do it, that is copied by too many developers the world over.

    To deal with your last example: the characters 999 represent something for the business, e.g. a gold customer account prefix. This is knowledge that should be kept centrally in the business logic. Your GUI should fetch this information from the business logic. So, if you were implementing in javascript with jsp, something like (I'm no jsp expert):
    if(accountNumber.startsWith('<% PremiumAccountBusinessObject.getAccountNumberPrefix() %>'){
    doWhatever();
    }

    Imagine for a moment that the customer got your solution, and later that month they merged with another company, which uses 222 as the prefix. Or they have different prefixes for each country, and you need to get the prefixes from a database.

    My example may be of limited use, but there are hundreds of things just like that in a large application. Hardcoding business information in GUIs makes the application extremely rigid and brittle. Having central business logic is the only way to make a maintainable, reuseable application that will stand the test of time.

    The customer almost never requests that you write quality, maintainable code, but that doesn't mean you should write rubbish code on purpose.

    xboob:
    just a brain fart


    A great example of the fact that "one mocks what one does not understand".

    /Michael


    so if I understand you correctly you want the presentation layer to request this informtion from the server on the lost focus event of the text box. When the server responds with the information you will hide the drop down list.

    The problem with your solution (which is rather slow) is that it still requires logic in the presentation layer to enable/hide the drop down list.

  • real_aardvark 2007-09-29 18:34
    xboob:
    <snip bollocks>
    MichaelR:
    <snip reasonably meaningful stuff>
    xboob:


    There is still no need for a business logic layer in your example.

    What you are talking about here is usualy just a brain fart of an idea and is never a request that comes from the client.

    Most of the business logic that acts on the data will be in stored procedures anyway. So this one be a problem without a business layer. Common functions to validate user input can be in a utility module that is shared between apps.





    Can you spell "assumptions"? You seem to have difficulty with anything else. Let alone grammar, or logical thought.

    Do, pray, explain why "most of the business logic that acts on the data will be in stored procedures anyway." I'd love to be bitch-slapped for having got this wrong for the last twenty years.
    MichaelR:

    xboob:

    Please tell me where you would place the code this request.

    Make the drop down list visible when the user enteres an account number in the textbox that starts with 999. This is client side business logic that will have to be duplicated on each form/page


    A fantastic example of how _not_ to do it, that is copied by too many developers the world over.
    xboob:
    just a brain fart


    A great example of the fact that "one mocks what one does not understand".

    /Michael

    so if I understand you correctly you want the presentation layer to request this informtion from the server on the lost focus event of the text box. When the server responds with the information you will hide the drop down list.

    The problem with your solution (which is rather slow) is that it still requires logic in the presentation layer to enable/hide the drop down list.


    Difficult to know where to start on this.

    "xboob" is clearly one character short of a perfect self-description. As MichaelR says, and I've never heard it before but it chimes in a sweet little way, "one mocks what one does not understand."

    "Please tell me where you would place the code in this request."

    Simple. In the business layer. That's a truly bizarre, and utterly arbitrary, requirement, but if I had to, I'd use the BL((c)Papadimoulis, 2007) to spit out javascript to check for "999" and do the business. I'd probably also use "999" to call for an ambulance and drag the idiot developer away to a mental hospital, but that's besides the point.

    Basically, if you're going to check for "999" on the client side, you're going to check for "999" on the server side. Same code. Same layer. Unless you're a complete idiot, and you are. You being Da Boob, not Michael. Sorry if that wasn't clear.)

    On the other hand, MichaelR needs to get out and about a bit. "Rather slow?" How about "Crippled and mentally deficient?" This is the problem with Web technology. You're all losing your minds, I tell you. It's crap, it's utter crap. it's indefensible crap, but that's where both Unix and MS Windows started from. Then they got faster. Nobody notices the crap any more.

    It's still there, but nobody notices.

    Gratuitously, I'm going to sling this MVC link in one more time:
    http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

    Read it. Learn. Think. Don't fuck around next time.

    mm'Kay?

  • real_aardvark 2007-09-29 19:00
    Mike:
    What a disappointment. To read all that rubbish only to find there is no demonstratable conclusion. WTF?!?

    Wow. You've read through all that rubbish, and still found the time to entertain us all with a witty comment?

    We are indeed indebted to you.

    BTW, "demonstratable" is typically spelled "demonstrable." Although your subsequent conclusion is not. Consult your local Socrates if required.

    Keep tugging the old rope. It won't help you spell better, or think more clearly. But it just might help you enjoy yourself more and stop you annoying the other six billion or so of us.
  • PimpinHoesDegree 2007-09-29 20:50
    All you bitch-ass-motha-fuckas that think the Business should be in a layer need to be slaped around.

    A stored procedure is like da shuga that a pimp gives to his hoes. There is no need for another pimp in da midle. A hoe can only have one pimp anyway. The pimp can directly lay his hoes in any place he sees fit. At the end of the day all that means anything is that those hoes are working and you don't need to slap them around too much. You understand what I'm saying motha-fuckas?


  • david 2007-09-29 23:33
    It addresses the fundamental centre of programming technique, which is why there is no simple answer.

    You can only make business logic orthoginal to program logic by expressing it in an orthogonal language (an inner platform).

    But an orthoginal language won't be any simpler than the original languge.

    Simplification (or any kind of optimisation) is achieved by choosing the appropriate transformation, or the appropriate problem domain. (Typical targets are all-noun scripts or all-verb transform layers).

    Which at this stage is still a matter of professional judgement.

  • Zygo 2007-09-30 03:46
    wbrianwhite:
    I would recommend that your DDL also be in source control. The company I'm at now is actually the first place I've seen a mandatory inclusion of all DDL in source control. Good god does it make life easier.


    I see your DDL in source control and raise you mandatory code reviews of
    said DDL. ;-)

    I have DDL in source control in two forms: one is a simple snapshot
    of the database's current state as DDL in a flat file checked in each
    revision. This is generated automatically from the DB.

    The other is a not so simple collection of DDL scripts with a versioning
    system that looks at a particular database instance and applies whatever
    scripts exist between the version in the DB and the current version.
    This is written by hand, although some people cut+paste it from the
    SQL conversation log files from some sort of GUI-driven DBA utility.
    Thank heaven for code reviews--they catch the side-effects of stray
    mouse clicks before they become production bugs.

    The first is semantically equivalent to a lot of "create table
    ..." statements while the other is a "create table ..." followed
    by many "add column ..." or "alter column ..." covering every change
    made to the database since version 0.

    The problem with generating the latter from the former (although it is
    often possible in simple cases) is that in general there is no way a
    code generator can derive a correct schema change from two arbitrary DDL
    snapshots when there is data in the schema. Someone who knows the domain
    has to figure out what to do when previously valid data becomes invalid
    due to new constraints or changes in relationships: do we silently
    replace invalid values with NULL, or delete the rows with offending data,
    or select a replacement value that is valid, or die with an error asking
    for the user to call the help desk, or do we shove all the offending
    data into a separate table and leave it on disk to rot until all human
    life is wiped off the face of the Earth by some celestial catastrophe
    (or an audit, whichever comes first)?

    Now, if you're talking to a LISP hacker, they'll probably tell you that
    your whole process is backwards. LISP programs can be written as a series
    of transformations which have a similar effect on the LISP environment
    as DDL statements have on an RDBMS. So if you want to edit your schema,
    you write some LISP which is interpreted by more LISP and the output
    comes out in the form of DDL commands for your RDBMS, Javascript for
    your web pages, and unified diffs for your C++ code. Version control
    is saving all the LISP statements in the order they were executed...

  • Zygo 2007-09-30 05:21
    real_aardvark:

    Life is, fortunately, not monochromatic, and both hammers and nails come in all shapes and sizes.


    Too right!

    I've got a bunch of hammers with big handles, small thin shafts, and
    pointy star-shaped heads. They would be completely useless, except that
    I also have a whole lot of nails with odd spiral-shaped metal going all
    the way down the shaft. The good thing is that the star shape on the
    head of the hammer fits into the star shape on the head of the nail,
    otherwise the nail would fly all over the place when I whack the hammer
    on the bottom of the handle with an old power supply transformer.

  • Zygo 2007-09-30 05:29
    real_aardvark:
    It's crap, it's utter crap. it's indefensible crap, but that's where both Unix and MS Windows started from. Then they got faster.


    Actually they aren't faster, in fact they are orders of magnitude slower.

    The only reason computers are usable at all today is that the people who make CPU's and memory chips have gotten more orders of magnitude faster during the same time interval when the software got slower.
  • real_aardvark 2007-09-30 11:58
    PimpinHoesDegree:
    All you bitch-ass-motha-fuckas that think the Business should be in a layer need to be slaped around.

    A stored procedure is like da shuga that a pimp gives to his hoes. There is no need for another pimp in da midle. A hoe can only have one pimp anyway. The pimp can directly lay his hoes in any place he sees fit. At the end of the day all that means anything is that those hoes are working and you don't need to slap them around too much. You understand what I'm saying motha-fuckas?



    Let me try.

    Hmmm. No.

    Would your stage name be T-Roll, perchance?
  • Kuba 2007-10-01 08:22
    wbrianwhite:

    What arrogance :) The DBA - who is the only one who can trace the actual performance, and who will still apparently have the right to go in and add indexes and whatnot, [...]


    I'd fully expect to cooperate with the DBA, but the performance tracing and whatnot should go into a built-in testsuite, such that performance regressions can be found before they bite. Similarly, for production, there should be code which will check on the performance and alert "proper people" (tm) if things go wrong. When you develop a "large enough" application, this is the only way to go IMHO, otherwise you need a whole staff to do what the software should be doing in the first place.

    wbrianwhite:

    By way, you are 110% WRONG if you think you can predict ahead of time which queries need which options. You can only find out what's needed by a trace of your production system running under normal load and analyzing performance. Optimization can almost never be done ahead of time, you need to analyze the actual bottlenecks in your system and improve them once it's already running. Otherwise you spend your time on things that take a long time and offer little benefit.


    We're dealing here with quite deterministic systems under somewhat undeterministic load -- you can in fact optimize ahead of time, and even tweak the optimizations adaptively as the system's load patterns change. People do lots of resarch on that and see real results.

    Again -- this is something that you need some with CS knowledge to deal with. I don't pretend to have that knowledge, I just know that the systems in question aren't really magic. Of course there are bugs and "weird" (undocumented) behaviors in the other software you deal with (database, ...), but those are usually bound by some, performance envelopes.

    wbrianwhite:

    The DBA would be redundant? Grow up. You're not smarter than everyone else. DBAs are better than developers at database performance tuning. It's their job.


    What DBAs do isn't magic, and there is only so much creative thinking (what machines don't do) that you need to apply to it. It's mostly boring, repetitive stuff. The thinking part can be distilled out; for a big system you then only need a part-time DBA (or just one DBA) vs. a whole army.

    wbrianwhite:

    And you think this approach is productive? It will take a minimum of hours by your own admission for this one simple task. Adding that one line to the one query and checking it into source control would take 10 minutes top.


    If it's all that easy then it can be automated. If it's not as easy, then you need to do some thinking about it anyway, and you might as well get the developer involved. The developer-DBA disconnect usually has disastrous consequences (IMHO).

    wbrianwhite:

    Kuba:

    This approach has the benefit that a lot of its functionality could be (with some more work) formally proven against requirements. It's not fragile at all. In fact, it offers a lot of built-in checks and there's no way to get the webpages, the middle tier and the database out of sync. It's all consistent from the get-go.


    That's fine.... until you get a requirement that the front end field be smaller than the db field.


    (gen::table &show-count 30 &columns 'firstName 'lastName 'age &setup
    
    (defun firstName-printer (page::field &shown-length 10 &inherit)))


    gen::table is a macro and it will evaluate its arguments in proper environment, such that:
    - definition of firstName-printer will override the default one
    - page::field knows the details of the field it's supposed to work on

    Pretty basic stuff.

    Kuba:

    It's not something that I'd expect a random web-developer to do. I enjoy learning, and I had to learn a lot in the process. If I were to do it in a development company somewhere, I'd be hiring a few accomplished Ph.Ds who really know about that stuff first.


    wbrianwhite:

    My apologies. You do think you're smarter than everyone else. Why would computer science Ph.Ds be doing web development work?
    And why do you assume they'd be good at it? There are many platforms that already exist for making web applications. You're not going to make a better platform on the side while focusing primarily on your application.


    I don't think that I'm smarter, I'm merely saying that most "web developers" would not have the knowledge necessary to develop such a system from scratch. Nor would I expect them to. I don't have it either. I based most of the techniques on resarch done by others. It's a (comparatively) very small project, mostly done as "hmm, why not?".

    As for why you need CS knowledge for that? Because most "platforms" used for developing web applications grew from either hacks (say php) or from approaches which were more of the same. To really innovate requires some research into the underlying techniques.

    AFAIK, both Yahoo! Stores and Orbitz started with pretty hardcore LISP-based technology that most so-called "web developers" wouldn't even consider.

    It's pretty yummy, yes.

    Cheers!
  • wbrianwhite 2007-10-01 12:47
    Zygo:
    wbrianwhite:
    I would recommend that your DDL also be in source control. The company I'm at now is actually the first place I've seen a mandatory inclusion of all DDL in source control. Good god does it make life easier.


    I see your DDL in source control and raise you mandatory code reviews of
    said DDL. ;-)

    I have DDL in source control in two forms: one is a simple snapshot
    of the database's current state as DDL in a flat file checked in each
    revision. This is generated automatically from the DB.

    The other is a not so simple collection of DDL scripts with a versioning
    system that looks at a particular database instance and applies whatever
    scripts exist between the version in the DB and the current version.
    This is written by hand, although some people cut+paste it from the
    SQL conversation log files from some sort of GUI-driven DBA utility.
    Thank heaven for code reviews--they catch the side-effects of stray
    mouse clicks before they become production bugs.





    Now, if you're talking to a LISP hacker, they'll probably tell you that
    your whole process is backwards. LISP programs can be written as a series
    of transformations which have a similar effect on the LISP environment
    as DDL statements have on an RDBMS. So if you want to edit your schema,
    you write some LISP which is interpreted by more LISP and the output
    comes out in the form of DDL commands for your RDBMS, Javascript for
    your web pages, and unified diffs for your C++ code. Version control
    is saving all the LISP statements in the order they were executed...



    Yes, we pretty much have this too. We don't have "a simple snapshot of the database's current state as DDL in a flat file" though. What is the purpose of that exactly? We just pull a scrubbed version of the live db, and use our utility program to apply all newer DDL files when we need to rebuild qa or set up new dev boxes.

    I've never used LISP except in an Autocad class. Given that I only ever hear about it online from less than 1% of programmers and never hear about it actually being used to drive major businesses, I think I'll remain skeptical. I'm particularly wondering how such a system would handle you upgrading from SQL 2000 to SQL 2005 or something similar? Queries that ran before no longer would, some queries will be faster, some will be slower, linked server performance will be impactd, XML load technology is completely changed, etc. Troubleshooting that at any remove from the actual system seems guaranteed to take longer than doing it directly in the db with the tool the db provides: DDL.
  • wbrianwhite 2007-10-01 13:33
    Kuba:

    I don't think that I'm smarter, I'm merely saying that most "web developers" would not have the knowledge necessary to develop such a system from scratch. Nor would I expect them to. I don't have it either. I based most of the techniques on resarch done by others. It's a (comparatively) very small project, mostly done as "hmm, why not?".

    As for why you need CS knowledge for that? Because most "platforms" used for developing web applications grew from either hacks (say php) or from approaches which were more of the same. To really innovate requires some research into the underlying techniques.

    AFAIK, both Yahoo! Stores and Orbitz started with pretty hardcore LISP-based technology that most so-called "web developers" wouldn't even consider.

    It's pretty yummy, yes.

    Cheers!


    So I looked up Orbitz and Lisp. A company called ITA Software wrote that engine you're talking about. Orbitz did not write it itself. What does that say to you? The articles I read also talked about the difficulty of finding good Lisp programmers. So, they outsourced development to a third party who gave them back their basic search engine. This has nothing to do with web development though. Nothing at all.

    Flight search is a complicated domain, and one I happen to know a lot about. There are multiple approaches to this problem. I personally view the approach they took as a solution looking for a problem. My company is competitive to Orbitz in certain arenas, and asked different questions and addressed different issues. I know for a fact that the ASP, C++ COM object, and SQL Server stack works perfectly well for this domain. Competition is on features, not on platform.

    We are of course constantly innovating. Our current focus is actually on AJAX-ifying the interface, a code issue that is particularly hard for any code generator. We're building on top of multiple AJAX libraries/platforms and adding our own stuff. What we are not doing is writing our own infrastructure platforms.

    WTF is yummy?

    I looked up Yahoo Stores and Lisp and found this:
    http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
    When one of the customer support people came to me with a report of a bug in the editor, I would load the code into the Lisp interpreter and log into the user's account. If I was able to reproduce the bug I'd get an actual break loop, telling me exactly what was going wrong. Often I could fix the code and release a fix right away. And when I say right away, I mean while the user was still on the phone.


    Can you tell me the two scariest things about that? Now I can't take this person seriously about anything they ever say about development if they think that's professional.

    Ah, it turns out that was when his company was 3 people. Then Yahoo bought them.
    http://www.psg.com/~dlamkins/sl/appendix-a.html

    So the two examples you provided - one was written by an outside consultant company and functions as a black box essentially, the other was purchased. At no point did Orbitz or Yahoo write their own platform. Please take note of that fact. Developers working on an actual business product almost never write their own platform, and what you're talking about is writing a platform. Instead a platform is purchased if necessary, from consultants, from service providers, or by buying a company who has already developed what you want.
  • jefrainmx 2007-10-01 16:23
    Not cool. You are like those guys that said that documentation sucks.
  • M 2007-10-02 02:58
    There are a few good points in that article, but some of the examples are horrid... they work against the author. Here an example of business logic from the article:

    When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.


    And then:

    A good system [...] has no choice but to duplicate, triplicate, or even-more-licate business logic


    It is evident that duplicating that particular sort of business logic quoted above is a very, very bad idea. On the other hand, duplicating mere constraints such as the length of 7 chars for an attribute seems to be less of a problem. The idea that a text search " will generally reveal exactly what needs to be changed, and where", is absurd, especially with a team of developers.
  • Ash002 2007-10-02 09:55
    * The Customers database table, with its Customer_Number (CHAR-13)... ==>> Just names not logic

    * The subroutine that extends a ten-percent discount to first time customers: definitely business logic. And hopefully, not soft-coded. ==>> Business logic

    * And the code that highlights past-due invoices in red: that’s business logic, too. ==>> The past-due bit is business logic, the color you display it in is view not logic. The same fact can be displayed in many ways, change the definiton

    Your comments on the DB layer remind me that OO business objects seem to overlook that most of what we do is *records* management, that we are not building a *project* object but a project record management object. So the record from the DB's project table is a valid sub object of the business object, responsibility is to store the data, while the BO is responisible for validating the record.

    I don't buy the stuff about field lengths needing to be hardcoded from ahole to breakfast time.

    A lot of the stuff you mentionjust sounds like bad design of objects, rather than a problem with the paradigm.

    The current enterprise client/server system I work on has 1600 stored procs with little reuse and was developed with a lot of cut and paste. It has now become difficult to maintain and change and is a victim of its own success, as it is now required to grow and expand with the company's success. Its one strength however is that there isn't too much business logic in the front end.
  • wbrianwhite 2007-10-02 12:21
    M:

    A good system [...] has no choice but to duplicate, triplicate, or even-more-licate business logic


    It is evident that duplicating that particular sort of business logic quoted above is a very, very bad idea.


    Is it also apparent that attempting to generate client-side validation from some server side business object also has big pitfalls? If your business decides to switch to an AJAXified front end your framework is then going to be a big stumbling block in making that switch. The framework that can easily spit out some simple javascript cannot so easily spit out a webservice listening for requests, the stored procs that act on it, and the more complicated javascript feeding and reacting to it.
  • Spaghetti Code Western 2007-10-03 01:32
    FredSaw:
    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).


    From Wikipedia:

    A business object encapsulates all the data and behavior (including persistence logic) associated with the object it represents.


    Fred, if wikipedia is right about CSLA (other sites contain similar descriptions of CSLA) then Rocky created a kludge and you bought it.
  • Fr 2007-10-03 02:00
    Ash002:
    * The Customers database table, with its Customer_Number (CHAR-13)... ==>> Just names not logic


    * And the code that highlights past-due invoices in red: that’s business logic, too. ==>> The past-due bit is business logic, the color you display it in is view not logic. The same fact can be displayed in many ways, change the definiton


    As others have said, if customer table and column names do not contain some amount of business logic then just name them table1,table2,... and column1, column2. While you could make the case for using the different data types to save space, is not going to use a BLOB type to store everything even if it saved space.

    While the colour used is view at some point you have to tell the view which items to display as that color. Most tools make it really easy and readable to do conditional formating in the view. Do you go and replace one line of easily readable and changeable view code for 50 lines in the business logic to duplicate this?
  • Zygo 2007-10-04 03:13
    wbrianwhite:
    Yes, we pretty much have this too. We don't have "a simple snapshot of the database's current state as DDL in a flat file" though. What is the purpose of that exactly? We just pull a scrubbed version of the live db, and use our utility program to apply all newer DDL files when we need to rebuild qa or set up new dev boxes.


    That's pretty much the same thing. The snapshot is DDL that goes directly from zero to the current database schema, as opposed to DDL that goes from each version to the next. It's sometimes useful to check the differences in the snapshots to ensure that the serial DDL revisions had the expected effects. We stress the RDBMS enough on some schemas to find bugs in the implementation (!) that show up this way.

    wbrianwhite:
    I've never used LISP except in an Autocad class. Given that I only ever hear about it online from less than 1% of programmers and never hear about it actually being used to drive major businesses, I think I'll remain skeptical.


    To be honest, aside from Yahoo Stores and Orbitz, I don't know of anyone using LISP in real life (except Cadence, who dominates the EDA market, and uses LISP as the automation integration language in every product they sell).

    I do know of one person in real life who runs a retail store on Prolog. Apparently it's really easy to write things like "orders under $250 must be charged for shipping" in Prolog.

    LISP has abysmal third-party library support. I read a blog post the other month talking about some startup company's site which officially gave up on LISP because they were basically maintaining an entire web development platform by themselves.

    Most of the interesting features of LISP have long since been copied to other languages. C++ templates are Turing complete, and if you can program in a functional language like LISP you can write and execute procedural code generators inside the C++ compiler. Perl has symbol table introspection, dynamic scoping, closures. PostScript is actually derived from Forth, not LISP, but I find that a lot of the concepts still work in both languages. Tcl borrows so many concepts from LISP (although alas absolutely nothing of the syntax) that some LISP code can be almost directly transliterated into Tcl.

    These days the price of giving up some non-LISP language to use LISP is too high to be practical in many cases. Tcl has very easy support for cross-platform development and integration with C, so it appears embedded in robotics and it's endemic in EDA application automation. Perl has CPAN, it works on all interesting platforms, and it appears preinstalled on nearly every Linux system on the planet. C++ has ISO standardization behind it and its runtime appears on nearly every system on the planet, Linux or otherwise.

    It's usually easier to implement the 5% of LISP you need for your project in some other language, than to implement 95% of the libraries your project depends on in LISP. So almost nobody uses LISP.

    wbrianwhite:
    I'm particularly wondering how such a system would handle you upgrading from SQL 2000 to SQL 2005 or something similar? Queries that ran before no longer would, some queries will be faster, some will be slower, linked server performance will be impactd, XML load technology is completely changed, etc. Troubleshooting that at any remove from the actual system seems guaranteed to take longer than doing it directly in the db with the tool the db provides: DDL.


    This depends on the nature of the changes to the queries. Purely syntactic changes are easy, you just change the code generator to emit queries with the new syntax (although if your code generator started out with ANSI compliant SQL syntax then there shouldn't be a problem unless the RDBMS vendor introduced a bug).

    Changes to query performance are no different during an upgrade than the changes that occur as data sets and query load are already changing day to day. I find I need to tweak schemas a few times a year when a performance hot spot appears--e.g. move a growing index onto a different disk array, or repartition a table. Very rarely do I have to change application code to do this--nor would I want to, really, as most of these changes are not functional in nature, and they're usually specialized to the unique conditions of data content and server hardware on the server I'm running.

    A code generator for queries assumes you actually have a need for non-trivial on-the-fly query generation. If you have something like the Bugzilla search page on your site, or if you're developing a product whose function is to generate other web sites, then you need such a query generator; otherwise, you can probably get by on a bunch of hand-coded queries, or stored procedures, or if you have a *lot* of similar tables, the occasional query string template which does simple string substitution for table and column names.

    In my experience if you're generating completely arbitrary queries (like the Bugzilla search page) then there's not very much you can do to optimize the query before the RDBMS ends up doing a sequential table scan. At that point performance tuning doesn't matter, since it won't change the time required to read the entire table from disk.
  • wbrianwhite 2007-10-04 11:31
    Zygo:

    I read a blog post the other month talking about some startup company's site which officially gave up on LISP because they were basically maintaining an entire web development platform by themselves.


    Yes, that's exactly what you want to avoid.

    Zygo:

    Tcl borrows so many concepts from LISP (although alas absolutely nothing of the syntax) that some LISP code can be almost directly transliterated into Tcl.


    I did work in Tcl back when it was the engine in Vignette. I found it to be too obscure a language as well. It was very hard to find anyone who knew either Vignette or Tcl, and with AOL nearby and using lots of Tcl they sucked up the available pool of developers experienced in Tcl. The online resources for Tcl were rather limited and seemed to be always shrinking, unlike those for Perl or other languages that were always growing. This was back in like 2000. It may have come back, I don't know. There was the same "maintain a platform" problem though to a lesser degree. When I needed to implement RC4 encryption using Vignette/Tcl, it was frustrating to find examples in ASP, Perl, and every other language under the sun except Tcl.

    Zygo:

    This depends on the nature of the changes to the queries. Purely syntactic changes are easy, you just change the code generator to emit queries with the new syntax (although if your code generator started out with ANSI compliant SQL syntax then there shouldn't be a problem unless the RDBMS vendor introduced a bug).


    Ha ha, nice. And what is the probability of a major database platform upgrade not finding a few bugs in corner cases? Then when you do, it seems easier to make the fixes only in those corner cases, and not make changes globally via changing your generator. Also, I find it better to take full advantage of the enhancements to base sql syntax your database provider gives you than to stick to ANSI, though I know others disagree.

    Zygo:

    A code generator for queries assumes you actually have a need for non-trivial on-the-fly query generation. If you have something like the Bugzilla search page on your site, or if you're developing a product whose function is to generate other web sites, then you need such a query generator; otherwise, you can probably get by on a bunch of hand-coded queries, or stored procedures, or if you have a *lot* of similar tables, the occasional query string template which does simple string substitution for table and column names.


    I see things the exact opposite. I think a code generator for your queries will only work on a small site, and will collapse when you get bigger. I have seen this happen in more than one company, and I'm talking fairly large companies here. If you have complex queries requiring temp tables and the like, it's far easier to write them directly than to try to generate them, and there are several times when temp tables are the most efficient answer.
  • ogilmor 2007-10-05 17:48
    Great article, Alex. Probaly one of your best, on a serious topic!
  • Zygo 2007-10-06 20:20
    wbrianwhite:

    I did work in Tcl back when it was the engine in Vignette. I found it to be too obscure a language as well. It was very hard to find anyone who knew either Vignette or Tcl, and with AOL nearby and using lots of Tcl they sucked up the available pool of developers experienced in Tcl. The online resources for Tcl were rather limited and seemed to be always shrinking, unlike those for Perl or other languages that were always growing. This was back in like 2000. It may have come back, I don't know. There was the same "maintain a platform" problem though to a lesser degree. When I needed to implement RC4 encryption using Vignette/Tcl, it was frustrating to find examples in ASP, Perl, and every other language under the sun except Tcl.


    One "problem" with Tcl is that it's so easy to integrate C code into Tcl that most people do exactly that, instead of providing a "native" Tcl implementation. Why translate RC4 into Tcl when you can just use a toolkit like SWIG, point it at a C implementation's "rc4.h", and have an instant Tcl API? The same thing happens with database libraries: AFAIK there's no database-agnostic interface librar for Tcl because it's about as easy to roll your own for Tcl as integrate one into C or C++ code (or just do all the DB stuff in C or C++ and export a domain-specific API in Tcl).

    In 2007 we're finding that many of our suppliers, partners, and competitors are using Tcl somewhere in their products, even if the sales guys don't know it, or are reluctant to admit it. We'll find that buried deep in a technical reference manual there's a paragraph that says something like "by the way, if you enable a certain checkbox then you can telnet to TCP port 17337 and send Tcl scripts to control the robot."

    I agree that it's hard to find Tcl developers. We have to grow all of our own. Managers seem to hate Tcl, but often we find sets of tools that have to speak to each other, and they often support multiple scripting languages each, but Tcl is the only one they have in common.

    wbrianwhite:

    Zygo:

    This depends on the nature of the changes to the queries. Purely syntactic changes are easy, you just change the code generator to emit queries with the new syntax (although if your code generator started out with ANSI compliant SQL syntax then there shouldn't be a problem unless the RDBMS vendor introduced a bug).


    Ha ha, nice. And what is the probability of a major database platform upgrade not finding a few bugs in corner cases? Then when you do, it seems easier to make the fixes only in those corner cases, and not make changes globally via changing your generator. Also, I find it better to take full advantage of the enhancements to base sql syntax your database provider gives you than to stick to ANSI, though I know others disagree.


    I think we've descended into violent agreement here.

    By "ANSI compliant" I'm thinking more along the lines of ensuring that all your identifiers are properly quoted and qualified so that queries don't suddenly become ambiguous when there's a new table in the schema or a new reserved word in the RDBMS implementation. It's usually a pain to write code that way, so I'll use macros or write some C++ classes to ensure that things are quoted properly.

    Even when I've used SQL code generators for most of a project, there are always some ad-hoc queries. Even the simplest project needs to tweak a few SQL settings at startup.

    wbrianwhite:

    Zygo:

    A code generator for queries assumes you actually have a need for non-trivial on-the-fly query generation. If you have something like the Bugzilla search page on your site, or if you're developing a product whose function is to generate other web sites, then you need such a query generator; otherwise, you can probably get by on a bunch of hand-coded queries, or stored procedures, or if you have a *lot* of similar tables, the occasional query string template which does simple string substitution for table and column names.


    I see things the exact opposite. I think a code generator for your queries will only work on a small site, and will collapse when you get bigger. I have seen this happen in more than one company, and I'm talking fairly large companies here. If you have complex queries requiring temp tables and the like, it's far easier to write them directly than to try to generate them, and there are several times when temp tables are the most efficient answer.


    Ever seen the Bugzilla query page? ;-) There's no way to implement that without a query code generator. The page *is* a UI-driven query code generator, allowing arbitrary boolean expressions over just about every column of the Bugzilla SQL tables.

    On the other hand, you hit the nail on the head about it not scaling--very large Bugzilla sites provide only a very restricted version of the query page. Once you deviate from simple search queries on indexed columns, queries degenerate into a full table scan--or even a multi-table full join--in the RDBMS. Using MySQL as a backend doesn't help performance much either.

    I think we may have different notions of "large sites." When writing the above, I was thinking of sites which implement e.g. a retail store interface for clients in the thousands. In this situation clients are told what business rules are implemented in the software, not the other way around. As the site scales, performance problems can be addressed either in software, or by simply partitioning customers across more hardware. In this case most of the SQL code should be very similar from one site instance to the next, so it can (should!) be generated automatically, or ad-hoc queries can simply have different parameters mechanically substituted as required.

    I think you are thinking of large sites with a single customer who dictates and changes the rules arbitrarily, and a lot of separately developed systems provide the implementation. In such cases I agree a code generator is futile, mostly because the requirements for integrating any two components of such a system are unique to the integration task. What language do you write the code generator in? What language does it output? Does a MS-SQL code generator written in C# help you with Oracle, C++, MySQL, Java, and PHP components? Do you use this generator for your new code, or do you replace all the existing code as well? Which of the half dozen design patterns does the code generator support? Can the code generator reliably do anything beyond declaring a struct type, accessor methods, and constraint checks (i.e. what the database already knows)? Does the code generator impose constraints on the runtime environment? Does the code generator work on all your implementation platforms? After answering just a few of these questions the whole idea seems ridiculous.
  • wbrianwhite 2007-10-08 13:20
    Zygo:

    Ever seen the Bugzilla query page? ;-) There's no way to implement that without a query code generator. The page *is* a UI-driven query code generator, allowing arbitrary boolean expressions over just about every column of the Bugzilla SQL tables.

    On the other hand, you hit the nail on the head about it not scaling--very large Bugzilla sites provide only a very restricted version of the query page. Once you deviate from simple search queries on indexed columns, queries degenerate into a full table scan--or even a multi-table full join--in the RDBMS. Using MySQL as a backend doesn't help performance much either.


    Wrong tool for the job probably. You do not want to use an RDBMS for this task. You would want to use a data warehouse approach to this task - a star schema with those columns as dimensions instead. RDBMSs are great for transaction systems. Data warehouses are great for arbitrary queries on large data sets.

    Zygo:

    I think we may have different notions of "large sites." When writing the above, I was thinking of sites which implement e.g. a retail store interface for clients in the thousands. In this situation clients are told what business rules are implemented in the software, not the other way around. As the site scales, performance problems can be addressed either in software, or by simply partitioning customers across more hardware. In this case most of the SQL code should be very similar from one site instance to the next, so it can (should!) be generated automatically, or ad-hoc queries can simply have different parameters mechanically substituted as required.


    I do not understand why there would be any different 'sites' involved in what you're talking about here. I've done this several places, on e-commerce sites that allowed affiliates to link in and change our layout, colors, text, etc. There was no need to go beyond a common codebase shared by all the sites. I'm not sure what you mean by ad hoc queries either. It is never necessary to pass sql strings to your db to just execute. If you absolutely positively have to have something like that, then you can do it with dynamic sql that is inside stored procedures. That at least keeps your interface with the db consistent and goes a long way to preventing sql injection.

    Zygo:

    I think you are thinking of large sites with a single customer who dictates and changes the rules arbitrarily, and a lot of separately developed systems provide the implementation.


    I'm again confused by your use of 'customer'. Are you a contractor? I'm just thinking of the company I work for. And yes, rules do change frequently. One group here used code generators for quite a while. They had to give up eventually because they were spending 10x more time on developing new thing X than a group not using a code generator. Was their implementation wrong? Maybe. But in my view a correct implementation would require you to be able to see 5 years into the future with precise detail to know how you need to build it, and that is impossible.

    I guess my definition of large is probably defined by my current company too. We have huge clients and are one of the top players in software as a service. We do complicated stuff that is best done directly in whatever tool you're using: sql, server side script, client side script, xsl, xml, webservices, .net, css, etc. Code generation would only be extra overhead in 95% of the cases. Why write a generator that can make code that launches 8 parallel processes to make xml requests and combine the results? That's hard enough to write directly, and you're never going to reuse it. There may be a certain domain where code generation is beneficial, I don't know. I do know it's never been actually needed in any of the environments I've worked in, from etailers to federal government, and that I've seen it hurt businesses using it.
  • Archie 2007-12-31 19:02
    Yep...and my dad can beat up your dad! That's what these endless debates remind of. I get a kick out of the OO guru's who turn spaghetti code into spaghetti models. What's the diff? You've just replaced the IF THEN ELSE mss with the inheritance mess. And what's worse, I have to open up 15 projects to see it in all of it's glory. Everything in moderation I always say...

    Here's what I see when these OO craziness goes to far:

    Manager: We need a system that allows us to update salaries for our employee table. Can you do that?

    OO Guy: Well sure. I took an extra couple of weeks to abstract out the entire business layer so we can maintain it independently of the systems that use it. See, I designed the "this" to act on "that". And "that" acts on "something". I wanted to be careful not to hardcode the "something" because then I couldn't use "that" to act on "another thing". I don't know what the "another thing" is yet, but I'm sure there will be "another thing". And don't get me started on "something else". I know that "something else" is going to benefit from me creating "that". Make sense?

    Manager: BTW, our employee table is going to be taken over by SAP. Does it work for "that"?

    OO Guy: Uh... Oh...
  • Maikel 2008-02-10 07:47
    I would like to define business logic as follows:

    Business logic = all logic that affects the perceivable state of a business.

    It defines how and when objects that are understood by people within the domain, are created, modified and communicated within well-defined business-oriented tasks.
  • Sanity 2008-03-01 21:48
    will:
    Not duplicating logic leads to horrid experiences for the user. There is no reason the average user should have to hit a submit button then wait for a response from a server to tell them that what they entered needed to be a number not a character.


    There are two ways of dealing with this:

    First, not all cases of generated Javascript are WTF-worthy. There is no reason you can't at least avoid duplicating column constraints. It won't work 100% of the time, but it will work often enough to save you time.

    And second, in some cases it's impossible to put the validation in the script, without some communication with the server. Picking a unique username, anyone?

    In that case, some of the better ones will send an asynchronous request every few seconds as the user types, validating the data. (Call it AJAX if you must.)

    Now, I do agree that "business logic" is perhaps a wrong term. "Application logic" might be better. But it is obvious that, at some point, a framework is needed -- at some points in the article, Alex seems to be telling us that we should not invent frameworks -- and he does indeed point to a strange one.

    But then, what do you call a database server?

    Certainly, not every app needs to build its own database server. And certainly, we should be honest about when we're building an app, and when we're building a framework. But at some point, someone had to come up with the idea of implementing a generic database server -- and I am not arrogant enough to think that such inventions are wholly behind us.

    (Invention, not innovation -- there is a difference. Initech does innovation.)

    I'll also say that I'm not entirely sure whether or not it's a good thing to try to abstract "business rules". Whether or not it's possible to do that and not end up on thedailywtf, I do think it's more important to make the job of updating and maintaining this logic easier on actual developers than to (try to) make it possible for non-programmers.

    As for LISP, it's worth mentioning that many of the better ideas from LISP have been absorbed into other languages. JavaScript is basically "LISP in C's clothing." Just about every language now has closures...
  • Web Developer 2008-03-12 11:35
    In web development, the "persistence layer" is a database, and the "presentation layer" is a web browser. Thus two of the three layers are already built, and the "business logic layer" includes nearly everything a web developer will ever write.

    Ok, that's not entirely accurate, because client-side JavaScript is usually considered part of the presentation layer, and database table definitions are part of the persistence layer. The point is that you should use standard building blocks when they fit the design. 20 years ago we built everything from scratch, but those days are gone.
  • Michiel Trimpe 2008-03-18 10:19
    I think the article is pretty true; a pure busines-logic layer is simply impossible. I've written an article once on what I call the DED-project: Do Everything Dynamically.

    What I think is missing from this critique however is that the code _doesn't_ need to be duplicated / triplicated or whatever. It needs to have a SPoD: Single Point of Definition.

    Somewhere in the meta-data archives there should be a data-definition (e.g. RDF & OWL) for the "Client Name" which could say that it equals the "Name" field which has a 'Maximum-Length' property of 7.

    This node should be referenced to create the Database Tables, the JavaScript Form Validation, the Controller's Validation and the Persistence API's Validation and from it the length of the form-field could be calculated.
  • Ryan 2008-03-19 01:28
    The problem is in the naming. I use Data Layer (for swappable data storage to any db, file persistence etc), Activity or Action layer (fills entities, caching, conversions, validations, etc). Then API Facade with other facade services for JSON, web service, remoting, etc. The problem is only in naming. It is not a business layer, it is an activity or action layer. The usage is not required it could just be DAL and API with services and entities but the act layer helps to provide a platform for the api to simplify it and provide a cachign layer that the api can manipulate if you so deem in data caching.
  • PissedOffGorilla 2008-07-16 11:06
    I work for a State department and have been developing in various languages for nearly half my life. I was taught to make the code work in the simplest way possible without compromising functionality or integrity. Unfortunately, whenever we bring on consultants, simple gives way to ridiculous levels of complexity and "efficiency" in their code. What that means to me, is when they leave I'm going to have to take a week just to dig down through their code and see what the hell they're doing just to change a button click event. Thank you for providing an article I can read whenever they're b.s. gets me fired up. Somehow me making the same argument as you tends to get lost in a see of expletives when I try to explain it.
  • Calvin 2009-01-16 12:50
    I like the suggestion of calling the layers:
    Database
    Processing
    UserInterface

    but then again all of the layers do processing, No? Duplication of logic is not a good idea because of maintenance, however, it is worth mentioning that duplication of logic depends on how the software is developed. If a single developer is developing the UI, BusinessLayer and Database then, consider the account number example in this article, can be validated only at the UI layer and should not be validated anywhere else even if the column in database is Varchar(1000). However, if multiple developers are designing it then, DBAs have to do their validation, middle tier developers will do their validation and UI developers will do their validation. But even then the UI and business tier can call a centralized function to check for validation (centralized.IsAccountValid(string accountNumber)).

    The best approach is to make your code readable, understandable and easy to follow. Do not try to be clever. Only be clever about finding the easiest solution possible.
  • Matt 2009-02-10 11:47
    So, this pretty much amounts to one of the worst programming articles I've ever read. Half of the respondents, and the author himself, obviously haven't written any systems more complex than "Let me put some data on a page, ayuck, ayuck".

    I can't believe it was suggested, with a straight face, that people should duplicate code two and three times. Do you even know what the word "maintainability" means? Is this the new "retro" movement in programming, to go back to the "glory" days of the 80's when most software was a festering pile of crap because of the very attitudes displayed in articles like this? "Designing things right is hard, it's hard for me to understand, so I'm just going to half ass it and duplicate code all over the place".
  • TMG Hell 2009-04-15 23:17
    Hibernate is quite possibly the worst terror one could inflict upon a database. Pulling down an entire 'object graph' that spans 100+ columns over 10+ tables to update a single field (hello 27,000 character generated sql statement) is the most ridiculous thing I've ever seen in programming. Hibernate is a good example to show why Artificial Intelligence will never happen.
  • LED display 2010-02-09 04:24
    <A HREF="http://www.ledtv.asia">LED display</A>
    <A HREF="http://www.ledtv.asia">LED Signs</A>
    <A HREF="http://www.ledtv.asia">LED Message display</A>
    <A HREF="http://www.ledtv.asia">LED Message Signs</A>
    <A HREF="http://www.ledtv.asia">LED board</A>
    <A HREF="http://www.ledtv.asia">LED curtain display</A>
    <A HREF="http://www.ledtv.asia">LED Soft curtain</A>
    <A HREF="http://www.ledtv.asia">LED soft display</A>
    <A HREF="http://www.ledsigns.cn">LED display</A>
    <A HREF="http://www.ledsigns.cn">LED Signs</A>
    <A HREF="http://www.ledsigns.cn">LED message display</A>
    <A HREF="http://www.ledsigns.cn">LED outdoor display</A>
    <A HREF="http://www.ledsigns.cn">LED fullcolor display</A>
    <A HREF="http://www.ledsigns.cn">LED board</A>
    <A HREF="http://www.ledsigns.cn">LED message signs</A>
    <A HREF="http://www.ledsigns.cn">LED panel</A>
  • LED display 2010-02-09 04:37
    <A HREF="http://www.ledtv.asia">LED display</A>
    <A HREF="http://www.ledtv.asia">LED Signs</A>
    <A HREF="http://www.ledtv.asia">LED Message display</A>
    <A HREF="http://www.ledtv.asia">LED Message Signs</A>
    <A HREF="http://www.ledtv.asia">LED board</A>
    <A HREF="http://www.ledtv.asia">LED curtain display</A>
    <A HREF="http://www.ledtv.asia">LED Soft curtain</A>
    <A HREF="http://www.ledtv.asia">LED soft display</A>
    <A HREF="http://www.ledsigns.cn">LED display</A>
    <A HREF="http://www.ledsigns.cn">LED Signs</A>
    <A HREF="http://www.ledsigns.cn">LED message display</A>
    <A HREF="http://www.ledsigns.cn">LED outdoor display</A>
    <A HREF="http://www.ledsigns.cn">LED fullcolor display</A>
    <A HREF="http://www.ledsigns.cn">LED board</A>
    <A HREF="http://www.ledsigns.cn">LED message signs</A>
    <A HREF="http://www.ledsigns.cn">LED panel</A>
  • None 2010-02-15 13:36
    TRWTF is that the business logic layer is supposed to contain the SPECIFIC DETAILS of a particular business function and is therefore not a "generic layer" as the author states.

    "There are already enough tools out there; your application does not need a generic layer."

    Before writing about a subject, maybe you should actually understand it.
  • youmeca 2010-02-19 22:20
  • numiniferous 2010-02-23 17:45
    Love this article, especially the bits about moving a problem from a layer only to create a bigger problem.
  • Mike 2010-04-06 09:30
    @Kindall Your response is excellent and well-thought.

    I completely agree with the separation of concerns that a three-tier architecture provides. I also agree with other comments regarding soft vs. hard logic. Logic (program-flow and logical constructs) should always be implemented in code. Data (such as a specific percentage) should always exist in the data layer where it should be made available for change by a non-programmer (perhaps even via the application itself!).

    At the same time, the "business logic layer" is really a bad name. I would call it the "control layer," since its purpose is really to do processing, and control communication between presentation and data layers.
  • dadinn 2010-04-13 06:24
    Agree. (+1)
  • hoodaticus 2010-08-11 21:34
    I’m sure those of you who managed to make it through that spec did not have visions of IF-ELSE code blocks swirling through your head. I’ll bet some of you, without even seeing the rest of specs, excitedly envisioned a CancelationWorkflowProvider that inherited from the abstract RequestWorkflowProvider and implemented the IPermissionRequired, IPropogationStatusRequired, and IExpenseAllocationTypeRequired interfaces, and was powered by the all-encompassing WorkflowManager. Why? Because that’s so much more challenging than writing a simple IF-ELSE code block.


    Actually, I saw a bunch of derived tables being joined to each other in a stored procedure that updates other tables (that have triggers in them that fire extended stored procedures), but to each his own.
  • D&G Ladies Leather Watches 2010-09-27 23:07
    unless you should concerning lAmid A smeach particular, certain equally discount Womens Watches though anyhow having the status of Jaquet Droz Watches Les Lunes, you surround come on the road on the road that the apposite stance. Cartier Watches Montres 21/Chronoscaph offers a deep get hold of of brin addition-name Audemars Piguet Watches Ladies Collection - Danaé at bizarre regards.we hope the so as topgreatest timbre of watch replicas friendly, in force type by the adjoining of side as well as the manufacturers to infer the most straight middling to repeat each one tyle, prepared of towering appraise equipment, afterward also species consideration. we retain crowd very inflexible quality stas well asards & material rudder to all suppliers.
    our Jaquet Droz Watches Les Lunes and Womens Watches are in effect the awfully as the primary ones having the status of including the welcoming price, high quality materials and imposing workmanship. sell Breitling Watches Aeromarine Collection - Colt Automatic is also publicized.
    our aim is to reserve you with first sort services as well as preeminent impressions watches, and issue your online shopping skill a wonderful one.9088232343002
  • James 2010-12-02 13:04
    "If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL"

    Am I missing something here? Why would you declare a seven DIGIT field as char rather than a numeric type???

    Disclaimer: I am NOT a programmer (and the question isn't rhetorical).
  • Joe 2011-12-14 17:27
    Account Number though sounds like it should be a data type of a number, isnt a true number. its more of an identification number.. like Social Security Number.. Telephone Number.
  • sarah 2012-05-15 00:09
    i have business layer review visit :
    http://blackeyedbunny.blogspot.com/
  • Cabo Roig 2013-08-02 08:31
    I should really mention that I have loved my visit to your high quality site, it puts many other individuals to shame, and has given me inspiration to make improvements to my own site about my home area of Costa Roig which is in Spain. Thanks for your hard work in establishing this blog and potentially 1 day you might be in a position to visit my web-site and pass some insightful responses. I would be pleased to welcome you and hear what you have to comment about it. Thanks yet again Costa Roig.
  • Wow 2013-08-12 16:41
    Jesus! Please tell me that you are not in the software business! And if you do please tell me that you are not building programs for missile systems!
  • Smithc498 2014-07-03 08:25
    There is numerous separate years Los angeles Weight reduction eating plan with each a person can be a necessity. The pioneer part can be your original obtaining rid of belonging towards the extra pounds. la weight loss gaeeeefcbkbbbake