• (cs)

    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 (unregistered) in reply to tieTYT
    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

  • (cs) in reply to Maximilianop
    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 (unregistered) in reply to wbrianwhite
    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 (unregistered) in reply to wbrianwhite
    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 (unregistered) in reply to wbrianwhite
    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 (unregistered)

    game developers use a scripting languaje to make the separation the game logic, and the core of the application (the engine).

  • Bernie Quick (unregistered)

    Never before have I left a comment. Never before have I seen someone prove over and over again what an idiot that are!

  • tieTYT (unregistered) in reply to xboob
    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 (unregistered) in reply to tieTYT
    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 (unregistered) in reply to xboob
    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.

  • (cs) in reply to Kuba
    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.

  • (cs) in reply to Geekwad
    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.

  • (cs) in reply to Kuba
    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to Corporate Cog
    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.
  • (cs) in reply to Kuba
    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 (unregistered)

    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 (unregistered) in reply to kindall
    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 (unregistered) in reply to titie
    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

  • (cs)

    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 (unregistered) in reply to titie

    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.

  • (cs) in reply to Fred768
    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 (unregistered)

    Layering is bad. TCP/IP has been a disaster so far - completely unworkable - layered architectures will never catch on.

  • (cs) in reply to Terry N
    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 (unregistered) in reply to Fred768
    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 (unregistered) in reply to wbrianwhite
    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 (unregistered)

    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.

  • (cs) in reply to Zygo
    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 :)

  • (cs) in reply to ET
    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.

  • (cs) in reply to Simmo
    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 (unregistered) in reply to clickonce
    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 (unregistered) in reply to real_aardvark
    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 (unregistered) in reply to Benjamin Smith
    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.

  • (cs) in reply to titie
    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 (unregistered) in reply to xboob
    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 (unregistered)

    What a disappointment. To read all that rubbish only to find there is no demonstratable conclusion. WTF?!?

  • xboob (unregistered) in reply to MichaelR
    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.

  • (cs) in reply to xboob
    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?

  • (cs) in reply to Mike
    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to wbrianwhite
    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 (unregistered) in reply to real_aardvark
    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 (unregistered) in reply to real_aardvark
    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.

  • (cs) in reply to PimpinHoesDegree
    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 (unregistered) in reply to wbrianwhite
    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!

  • (cs) in reply to Zygo
    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.

  • (cs) in reply to Kuba
    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.

Leave a comment on “The Mythical Business Layer”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article