SitePoint Sponsor

User Tag List

Results 1 to 5 of 5

Hybrid View

  1. #1
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    A single layer of cleverness?

    I may not be the best person to comment on Rails, having come foul of David once or twice before. Re-reading those it's interesting (at least for me) - many things have changed.

    Anyway - was reading Choose a single layer of cleverness and thinking "Yes but...". Jason and Selkirk made points to that effect here.

    The problem I have is my gut tells me something else here. Despite all the thought that's gone into better ways of designing software in recent years, why is it projects built on, say, Oracle with PL/SQL stored procedures and violations of most of modern software "good sense" are often part of the applications that actually "work" in reality, and keep on working?

    Perhaps that relates to the distinction Martin Fowler makes (and David linked to) between application and integration databases - think any application database will disintegrate into an integration database the moment it starts to mature.

    Martin Fowler also said don't distribute - somehow I'm not convinced by the idea of Rail's domain model as an integration point. Somehow need input from John Lim here.

    [Side Note / Confession: so far have done nothing more than read Rails tutorials and look at API docs]

  2. #2
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I agree with David here. I also think stored procedures shouldn't be used simply because the logic is not for the database to handle and I actually believe in separation of concerns. After all, that's what made the shared-nothing architecture succesfull, no ? I for one do not miss FoxPro.

    If talking good design vs design that works, "good design" is such a relative term you can't even define it. You cannot find a pattern here. And I really think design patterns are overrated and overused.

    Can't comment on ActiveRecord yet. Don't have enough experience.

  3. #3
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I disagree, but I am probably bias becuase it is my prefered development methodology. The reason I capture business logic in the database layer is that the web is not my only presentation method or consumer of the business logic rules. In our environment, I also have to contend with PowerBuilder or other client/server based applications and unix batch jobs manipulating the data. In this environment coding the business logic in a single location is far preferable to trying to encode the same set of rules in multiple applications stacks (DRY anyone?). PHP makes a great web presentation layer on top of this business logic.

    Making a single complexity layer might be the right choice, but make sure the layer is deep enough to be used by all clients of your business logic.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #4
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I disagree, but I am probably bias becuase it is my prefered development methodology. The reason I capture business logic in the database layer is that the web is not my only presentation method or consumer of the business logic rules. In our environment, I also have to contend with PowerBuilder or other client/server based applications and unix batch jobs manipulating the data. In this environment coding the business logic in a single location is far preferable to trying to encode the same set of rules in multiple applications stacks (DRY anyone?). PHP makes a great web presentation layer on top of this business logic.

    Making a single complexity layer might be the right choice, but make sure the layer is deep enough to be used by all clients of your business logic.
    I actually agree, I have to spend a good portion of my day writing PL/SQL for a very large project, and as much as I dislike it, the design methodology does have its advantages. We have a system that has to be usable and updatable by many different people in different languages, and therefore putting all of our business logic in PL/SQL packages and procs makes it easier for us to guarantee the logic is in place no matter who is doing the work.

  5. #5
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sgarissta
    I actually agree, I have to spend a good portion of my day writing PL/SQL for a very large project, and as much as I dislike it, the design methodology does have its advantages. We have a system that has to be usable and updatable by many different people in different languages, and therefore putting all of our business logic in PL/SQL packages and procs makes it easier for us to guarantee the logic is in place no matter who is doing the work.
    You can have a good design without having to resort to stored procedures. That's what the 3-tier architecture is for. Of course it adds to the complexity of the app. Nobody likes SOAP anymore, RPC in general is considered a security threat, and I haven't been hearing anybody saying good things about EJBs from quite some time. But, besides the fact that PL/SQL is not the language I want to code my logic in, having to write stored procedures will get you vendor lock-in. If you can live with it, that's fine. This kind of decision really depends on the task.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •