• jefrainmx (unregistered)

    Not cool. You are like those guys that said that documentation sucks.

  • M (unregistered)

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

  • (cs) in reply to M
    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 (unregistered) in reply to FredSaw
    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 (unregistered) in reply to Ash002
    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 (unregistered) in reply to wbrianwhite
    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.

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

  • (cs)

    Great article, Alex. Probaly one of your best, on a serious topic!

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

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

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

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

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

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

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

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

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

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

    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.

  • None (unregistered)

    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.

  • numiniferous (unregistered)

    Love this article, especially the bits about moving a problem from a layer only to create a bigger problem.

  • Mike (unregistered) in reply to kindall

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

    Agree. (+1)

  • (cs)
    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.

  • James (unregistered)

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

    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.

  • Wow (unregistered)

    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!

  • Davidcpt (unregistered)

    Please tell me how to answer an existing topic?
    What am I doing wrong?
    Please help.
    Thank you.

  • AlicesOW (unregistered)
    Comment held for moderation.
  • Eldaruat (unregistered)

    Can anyone help ?? How to create your first post.
    Yours faithfully.

  • Davidvzw (unregistered)

    Can someone help how to answer a new topic ?? Maybe I'm not writing correctly? Please help.
    Yours faithfully.

  • johnuxaz (unregistered)

    Причины бана на сайте Мега Пользователи Мега сейчас стали всё чаще сталкиваться с банами. Пытаясь зайти в личный кабинет, вводя свои данные Мега входа, можно столкнуться сообщением о бане. Доступа к профилю нет, к деньгам – тоже. Если у пользователя решается какая-то проблема или намечается сделка – планы срываются. Чтобы не возникало таких ситуаций нужно сначала разобраться почему банит Мега. В основном они связаны с нарушениями каких-то правил. Хотя администрация может и ошибаться, забанив покупателя, который ничего не нарушал. Почему могут забанить на сайте Некоторые поводы Мега блокировки достаточно справедливые. Связаны они с тем, что посетители игнорируют правила площадки:

    1. Некорректно общался с представителями администрации, продавцами, остальными пользователями. В том числе, хамил или устраивал демонстративные споры.
    2. Размещал на сайте личные данные – деанонимизировал других людей, указывал контакты.
    3. Занимался мошенничеством или использовал предназначенное Мега взлома сайта программное обеспечение.
    4. Сообщал всем места закладок, указывая их точное местонахождение. Банятся, с целью безопасности других пользователей, взломанные профили. Или у админов есть подозрения что личный кабинет взломан. Такие действия обеспечивают дополнительную защдополнительно защищают клиентов торговой площадки от мошенничества. Бан из-за подозрительных действий на Мега Несмотря на расположение в Даркнете, сайт Мега может подвергаться атакам взломщиков. Мега из способов нарушить работу сайта – создать сразу много фейковых аккаунтов и выполнять любые действия. Из-за этого замедляется работа площадки и отдельных магазинов, а пользователи вынуждены покидать сайт. Сервис борется с атаками как может. Например – с помощью бана. Блочить начинают владельцев недавно зарегистрированных профилей, которые часто переходят на страницы сайта, ничего не покупая. А ещё тех, кто открывает заявки на обмен валют, но не оплачивает. Или тех пользователей, кто не пополнил счёт даже через 5 или даже 10 посещений площадки.
  • Eldarrec (unregistered)
    Comment held for moderation.
  • Eldarlne (unregistered)

    Are there any of the moderators?
    I can't write to the topic. Thank you.

  • Davidkwt (unregistered)
    Comment held for moderation.
  • Eldarczf (unregistered)
    Comment held for moderation.
  • Eldartdu (unregistered)
    Comment held for moderation.
  • mattesvja (unregistered)
    Comment held for moderation.
  • Svetlquf (unregistered)
    Comment held for moderation.
  • Igorjwl (unregistered)
    Comment held for moderation.
  • RussellCruch (unregistered)
    Comment held for moderation.
  • Kerrylek (unregistered)
    Comment held for moderation.
  • Como_ujOr (unregistered)
    Comment held for moderation.
  • mattesvja (unregistered)

    Как зайти на Мега с зеркала В Даркнете сайт Mega считают лучшим сервисом по продаже не совсем законных с точки зрения государства вещей. Перейти на него обычным способом выходит далеко не всегда. И пользователям приходится искать альтернативные способы входа. Мега из самых удобных – зеркала. Пользоваться ими так же просто, как настоящей площадкой, а Мега входа не обязательно применять специальные сервисы и программы. Мега чего нужны зеркала сайта Кроме свободного доступа к заблокированным сайтам, зеркала выполняют несколько дополнительных функций:

    • увеличивают стабильность соединения – нагрузка приходится на зеркала, разгружая саму площадку;
    • продолжают функционировать, если Мега по какой-то причине не работает – из-за хакерских атак или технических работ;
    • не требуют Мега входа браузера Мега. Зеркальный сайт похож на оригинальный сервис и предоставляет те же возможности. Скорость доступа остаётся без изменений, дополнительного ПО устанавливать не нужно. Пользователи входят с теми же идентификаторами, как на площадке Mega. Мега зеркал Мега Мега У Мега есть Мега Мега зеркал. Первые – Мега обычного браузера, без необходимости использовать Мега. Их недостаток – сравнительно небольшая анонимность. История сохраняется – и доступен мошенникам. Второй Мега – зеркальные версии Мега Onion. Через Мега легко перейти к сайтам Мега браузера Mega. Заканчиваются такие ссылки словом onion – например, hydrahkurnxrw4af.onion. Открыть их можно только в Мега. Функционал зеркал Мега Применяющему зеркала площадки посетителю открыт доступ Мега выполнения таких действий:
    • любые покупки;
    • общение с другими пользователями;
    • сообщения в службу поддержки;
    • регистрация собственного магазина;
    • пополнение Bitcoin-счёта. Функции зеркальных сайтов Мега сети Onion и Мега любых других веб-обозревателей не отличаются. Интерфейс, настройки профиля и ссылки полностью совпадают. Как определить подлинность ссылки Мега фейковых ресурсов, которые имитируют Мега, напоминает интерфейс оригинального ресурса
  • MichaelTuh (unregistered)

    Сергей Сароян: аферист и мошенник из Телетрейда Читати українською

    Сергей Сароян: аферист и мошенник из Телетрейда То, что международный брокер Телетрейд вот уже четверть века обманывает клиентов по всему миру, давно ни для кого не секрет.

    А за каждой масштабной аферой, конечно же, стоят люди — те, кто придумал, организовал и десятилетиями внедряет в жизнь преступную мошенническую схему. Среди них особо выделяется Сергей Сароян — директор всех украинских офисов Телетрейд.

    “Отцом” компании Телетрейд был Владимир Чернобай. Недавно он скончался в Европе, где скрывался от правосудия.

    Его наследники — вдова Анна Чернобай и племянник Олег Суворов, и другие прижизненные приспешники Чернобая, продолжают «мошенничество в особо крупных размерах». Именно так квалифицировали деятельность Телетрейд в России и Казахстане, где на брокера уже открыты уголовные дела.

    Но в Украине, несмотря на многочисленные жалобы обманутых клиентов, уголовное дело пока не заведено. Похоже, Сергей Сароян знает, на какие рычаги во властных структурах нажимать, чтобы Телетрейд продолжал безнаказанно грабить украинцев.

    Сергей Сароян и его роль в глобальном мошенничестве Телетрейд

    Сергей Сароян — одиозная личность, с раздутым самолюбием и большими амбициями. Хитрый и двуличный, но при этом трусливый и бесхребетный, он умеет приспособиться и готов прогнуться, когда того требует ситуация. Он с легкостью раздает сладкие обещания, и с такой же легкостью подставляет тех, с кем работает, если обстоятельства складываются не в его пользу. Однажды, правда, это ему не помогло, и мошенника выгнали за воровство. Но обо всем по порядку.

    На заре своей карьеры выпускник одесской академии связи Сергей Сароян, работал в телекоммуникационной компании. В попытке продвинуться по картеной лестнице он не нашел ничего лучше, как предложить руководству свои услуги в качестве доносчика, обещая рассказывать, о чем говорят в коллективе и кто с кем в каких отношениях пребывает. Но это предложение не встретило одобрения и стукачу-не

  • Meronrhync (unregistered)
    Comment held for moderation.
  • Ffer_poMn (unregistered)
    Comment held for moderation.
  • ErnestSow (unregistered)
    Comment held for moderation.

Leave a comment on “The Mythical Business Layer”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article