Discussions

News: To Layer or not to Layer? That is the Architectural Question

  1. From "To Layer or not to Layer? That is the Architectural Question:" It's a commonly accepted practice when designing large scale enterprise applications (or even smaller applications for that matter) to layer your architecture code as well as your application code.

    Separation of concerns - for example, separating your business logic from your data access logic, or your presentation logic from your business logic - is a common technique for ensuring that your application code is well defined in terms of it's responsibilities. This approach gives you code that is easier to maintain and easier to debug - if you have a problem with the data access then you know to look in code in your data access layer.

    In Java-based applications, this capability is often taken too far. Mr. Hooke describes writing an application in PHP, where business logic is expected to be put in the presentation layer, and describes it as such: "From being in the frame of mind where I am encouraged to 'separate, separate', 'build more layers!', this is a refreshing change - I can develop pages in a fraction of the time than it would take me with a typical J2EE layered approach! Why? Because I don't have to develop additional plumbing code to interact between my many layers."

    His summary:
    As a development community though, we need to spend time thinking about how we can maximise the benefits gained from approaches such as architectural and application layering, while reducing the overhead of this type of approach, somehow avoiding the overhead of having to write the additonal code calling through from layer to layer. I haven't spent much time with Ruby on Rails, for example, but from what I can see with their approach they have maintained the design patterns typical in J2EE applications, but have replaced the need for the developer to spend so much time writing plumbing code - this is handled pretty much by the framework itself. This is where I believe we need to be heading.

    Threaded Messages (61)

  2. IMO[ Go to top ]

    My opinion is that it's always a good idea to put data access logic in seperate layer. However often it's impossible to separate business logic in a clean and elegent way.

    The benefits of layering is not just increased maintainability. The main advantage is that you can have some re-usable code in GUI layer. Of course, it's not possible if you have hardcoded SQLs in all JSP pages. :-)
  3. Really nothing new...[ Go to top ]

    It's the same old feeling that OOP, layers, sophisticated design and all other buzz, hypes and theories are supposed to every single project in and out of Earth.

    Right tools for the right job..isn't something like that we used to say?
  4. Really nothing new...[ Go to top ]

    It's the same old feeling that OOP, layers, sophisticated design and all other buzz, hypes and theories are supposed to every single project in and out of Earth.Right tools for the right job..isn't something like that we used to say?

    [I think 'Right tools for the right job' has to be one of the most over-used phrases in IT - the implication being that even small IT shops should lightly switch between PHP, Java, PERL, C++ or different development strategies depending on the task. Of course, this requires a huge and constantly updated set of skills for all developers and makes code reuse a real problem. It makes far more sense to build up serious skills and code libraries in a general-purpose language and to use general design approaches that scale well both up and down.]

    Things like OOP and 'layers' (what we oldies call 'encapsulation') aren't buzz and hype or theories - they have been a practical and important part of serious software design for decades.

    With modern refactoring IDEs, separating code into separate layers should not be a major part of development. I just don't agree with the article that there are significant costs in development time and additional effort, and resulting clarity of code can be a real benefit even in the smallest projects.
  5. Really nothing new...[ Go to top ]

    [I think 'Right tools for the right job' has to be one of the most over-used phrases in IT - the implication being that even small IT shops should lightly switch between PHP, Java, PERL, C++ or different development strategies depending on the task. Of course, this requires a huge and constantly updated set of skills for all developers and makes code reuse a real problem. It makes far more sense to build up serious skills and code libraries in a general-purpose language and to use general design approaches that scale well both up and down.]Things like OOP and 'layers' (what we oldies call 'encapsulation') aren't buzz and hype or theories - they have been a practical and important part of serious software design for decades.With modern refactoring IDEs, separating code into separate layers should not be a major part of development. I just don't agree with the article that there are significant costs in development time and additional effort, and resulting clarity of code can be a real benefit even in the smallest projects.

    Incredibly well said! +1!
  6. Encapsulation?[ Go to top ]

    Well afaik encapsulation is an object-level term. I wouldn't mix this up with the multiple architectural tiers what the article is all about (but granted, I'm not one of those oldies either)
  7. Encapsulation?[ Go to top ]

    Well afaik encapsulation is an object-level term. I wouldn't mix this up with the multiple architectural tiers what the article is all about (but granted, I'm not one of those oldies either)

    No. Encapsulation is a concept that applies to arbitrary levels of granularity ... classes, components, subsystems, layers, applications, etc. It is not even specific to OO.

    Regards,
        Dirk
  8. Really nothing new...[ Go to top ]

    It's the same old feeling that OOP, layers, sophisticated design and all other buzz, hypes and theories are supposed to every single project in and out of Earth.Right tools for the right job..isn't something like that we used to say?
    [I think 'Right tools for the right job' has to be one of the most over-used phrases in IT - the implication being that even small IT shops should lightly switch between PHP, Java, PERL, C++ or different development strategies depending on the task. Of course, this requires a huge and constantly updated set of skills for all developers and makes code reuse a real problem. It makes far more sense to build up serious skills and code libraries in a general-purpose language and to use general design approaches that scale well both up and down.]Things like OOP and 'layers' (what we oldies call 'encapsulation') aren't buzz and hype or theories - they have been a practical and important part of serious software design for decades.With modern refactoring IDEs, separating code into separate layers should not be a major part of development. I just don't agree with the article that there are significant costs in development time and additional effort, and resulting clarity of code can be a real benefit even in the smallest projects.

    Absolutely. As I've said before, using Struts, Spring, and Hibernate, I have what I think is a downward and upwards scalable framework fit for small and large projects.

    Which is easier? Jumping from a larger to small project or small to large when they both use the same framework, or jumping from one to the other when one uses PHP, the other ROR, the third Perl, etc...

    In fact, even small projects using the same framework have value for larger. Because of the needs of a small project that had to integrate with another system via an slow API, I had the opportunity to create an AOP advice(via Spring and OSCache) for caching.
    Now, the next time such a project rears its head, I've got the framework code in place...for any size project.
  9. Really nothing new...[ Go to top ]

    Things like OOP and 'layers' (what we oldies call 'encapsulation') aren't buzz and hype or theories - they have been a practical and important part of serious software design for decades.

    I believe maybe I wrote it in the wrong way, I didn't say it is new, doesn't work or anything, but it's not just because it works and is and old thing that it leaves the hype session. We've seen intersting concepts and techniques overhyped all over.

    In fact, I'm not sure but I think layers (the way the word is used nowadays) are too close of the concept of coarse-grained component.
    With modern refactoring IDEs, separating code into separate layers should not be a major part of development. I just don't agree with the article that there are significant costs in development time and additional effort, and resulting clarity of code can be a real benefit even in the smallest projects.

    Good point.

    Agree. I think that most RAD tools/environments I know by now are good almost only for prototypes. For real extensible projects, applying good design principles is a must.
  10. How much seperation is needed ?[ Go to top ]

    while it is true that the java community has "over emphasised" the use of layers in J2EE application designs, layers do bring some important benefits. I believe the amount of seperation required depends on the complexibility, maintainability (how often the requirements change), lifetime (how long you expect the application to be in production) of the application.

      I have really horrible experience with applications that were designed as monolithic systems,when we decided to replace the presentation layers with a latest technologies such as JSP/struts.

    sn
  11. I think the article author's opinion relates to Mickey Mouse projects only. Personally I cannot see how one would want to ever make an application where the business logic is tightly coupled to the presentation logic - and I definetely wouldn't want to work that myself. Imagine the pain..

    The reason (to name just a single one) - testing. How on Earth can you possibly find an intelligent way to test an application where you dump all your logic (business or infrastructure related) directly into the presentation tier? Unless you think functional testing from the end-user point-of-view is exceptionally funny and a good way of spending your clients' time and money.
  12. As a development community though, we need to spend time thinking about how we can maximise the benefits gained from approaches such as architectural and application layering, while reducing the overhead of this type of approach, somehow avoiding the overhead of having to write the additonal code calling through from layer to layer. I haven't spent much time with Ruby on Rails, for example, but from what I can see with their approach they have maintained the design patterns typical in J2EE applications, but have replaced the need for the developer to spend so much time writing plumbing code - this is handled pretty much by the framework itself. This is where I believe we need to be heading.

    I have seen many PHP / ASP developers putting business logic inside pages. On the other side, I have not seen so much need for code reuse since very frequently single use cases are realized by single views.

    That said, I think it is common sense that layering should be directly proportional to the complexity of the application - assigning the right responsibilities to layers saves from many headaches in the long term.

    Summarizing, I personally suggest my minimal layering:

    1) Presentation (I am currently using JSF);
    2) Services;
    3) Object model.

    Optionally, a DAO layer could be used, but only if you plan (and I don't think this happens frequently) you are possible about changing the ORM / data access framework.

    Alessandro
  13. As a development community though, we need to spend time thinking about how we can maximise the benefits gained from approaches such as architectural and application layering, while reducing the overhead of this type of approach, somehow avoiding the overhead of having to write the additonal code calling through from layer to layer.

    One word: spring
  14. One word: spring

    I don't think Spring completely addresses all the issues of the article. Spring provides a practical yet elegant way to access layers, not a way of organizing them.
  15. I don't think Spring completely addresses all the issues of the article.

    I think Spring addresses most of them. The author describes a five-layer architecture, where two of the layers consist of nothing but plumbing code to decouple his app from the SLSB API. With Spring, those two layers completely disappear.

    Layers are not the problem. Layers are just an organizational tool for where to put your methods. So unless you plan to implement your app in one big method, you won't save coding effort by getting rid of layers.

    The problem is plumbing code, which does add lots of coding effort. Spring is a moderate approach to eliminating plumbing code without losing your organizational capabilities. I feel the PHP and RoR approaches are overreactions to the plumbing problem that throw the baby out with the bathwater.
  16. I feel the PHP and RoR approaches are overreactions to the plumbing problem that throw the baby out with the bathwater.

    +1
  17. At least learn some netiquette..[ Go to top ]

    ..if you don't have anything to say.

    http://www.dtcc.edu/cs/rfc1855.html

    "Avoid posting 'Me Too' messages, where content is limited to agreement with previous posts. Content of a follow-up post should exceed quoted content."
  18. ..if you don't have anything to say.http://www.dtcc.edu/cs/rfc1855.html"Avoid posting 'Me Too' messages, where content is limited to agreement with previous posts. Content of a follow-up post should exceed quoted content."

    +1 (Just kidding)
  19. At least learn some netiquette..[ Go to top ]

    ..if you don't have anything to say.http://www.dtcc.edu/cs/rfc1855.html"Avoid posting 'Me Too' messages, where content is limited to agreement with previous posts. Content of a follow-up post should exceed quoted content."

    -1
  20. The author describes a five-layer architecture, where two of the layers consist of nothing but plumbing code to decouple his app from the SLSB API. With Spring, those two layers completely disappear.

    I agree, ProxyFactoryBean or dependency injection itself, do reduce "plumbing" efforts.
  21. I agree, ProxyFactoryBean or dependency injection itself, do reduce "plumbing" efforts.

    Sigh, no they do not. Dependency Injection replaces configuration. Configuration can never ever reduce plumbing. Instead putting your plumbing into a Factory and call that directory

    LayerFactory.getLayerObject().doLayering()

    you call it directly

    aLayerObject.doLayering()

    The plimbing effort, I am afraid is in the factory, and that can be configured or not but it must still be built and declared programmed, be it in Java, in XML or whereever.

    What DI gives you is independence of the concrete implementation of aLayerObject.
  22. Sigh, no they do not. Dependency Injection replaces configuration. Configuration can never ever reduce plumbing. Instead putting your plumbing into a Factory and call that directoryLayerFactory.getLayerObject().doLayering()you call it directlyaLayerObject.doLayering()The plimbing effort, I am afraid is in the factory, and that can be configured or not but it must still be built and declared programmed, be it in Java, in XML or whereever.What DI gives you is independence of the concrete implementation of aLayerObject.

    I see your point, it is (still) in the factory but, afterall, it reduces developer's efforts - because framework provides it.
  23. of course to layer[ Go to top ]

    Nothing new - the architecture depends on requirements, but I think you don't need over 50 developers to appreciate well defined layers. Especially when using frameworks helps to reduce the "plumbing code" overhead.

    PHP's easy of use is nice at the beginning but eventually turns to be hard to maintain, test, scale, whatever hell.
  24. The article describe the layers you need when using Ejb technologie. You need so many layers because:
    - EJB are distributed component
    - EJB are awkward
    If you want to be able to distribute your application it will always be more complex.
    Ruby on rails and most php application don't have the goal to support a distributed component model and hence are less complex.
    Before starting to develop an application with the java platform ask the good questions:
    Do I need to distribute?
    Do I need to support transaction?
    ...
    And then choose the right technologies and architecture and layers
    Java is not equal to J2EE
    J2EE is not equal to EJB
  25. Piling on EJBs[ Go to top ]

    Your last two questions are key ones. The bottom line is that a high-volume, transactional system is probably going to require what EJB has to offer.

    After you've done your first stateless session bean, especially with ant/ejbdoclet, then you've done them all. In other words, and IMHO, EJB is not terribly awkward. Today, it's just a matter of getting familiar with the appropriate tools.

    If you don't want your application to be be distributed, then don't. Just because you've got ejbdoclet annotations in your code doesn't mean you can't do a "new" to get a service layer component, in place of looking it up. It's all a matter of judicious use of factory methods.
  26. Piling on EJBs[ Go to top ]

    Your last two questions are key ones. The bottom line is that a high-volume, transactional system is probably going to require what EJB has to offer.After you've done your first stateless session bean, especially with ant/ejbdoclet, then you've done them all. In other words, and IMHO, EJB is not terribly awkward. Today, it's just a matter of getting familiar with the appropriate tools.If you don't want your application to be be distributed, then don't. Just because you've got ejbdoclet annotations in your code doesn't mean you can't do a "new" to get a service layer component, in place of looking it up. It's all a matter of judicious use of factory methods.
    But many high-volume system usually will benefit from being a collocated system (as opposed to the distributed one). The main (IMHO) advantage of the distributed system is that each box will be able to utilize it's memory just for a particular task. App layer box can use it's RAM for the Hibernate's second level cache or something like this, and the web layer box will be able to use it's RAM for JSP cache. Yet, in most cases the cost of RMI and other issues will make the overall system less per formant then if it was a collocated system. I believe that Google for example uses distributed model in some form (kinda like all words starting with A will be stored in the cluster of boxes #1, all words starting with B will be stored in the cluster of boxes #2, and so on). To truly utilize this model though you need a very particular architecture that most aps do not have. An example of the this architecture would be for instance trying to emulate large, in memory database by caching it on a cluster of boxes where each box will handle a part of the database.
  27. Piling on EJBs[ Go to top ]

    But many high-volume system usually will benefit from being a collocated system (as opposed to the distributed one).

    That is almost always correct, if by "distributed" you mean "EJB on one server, JSP on the other". Again, first law of distributed computing .. don't.
    The main (IMHO) advantage of the distributed system is that each box will be able to utilize it's memory just for a particular task. App layer box can use it's RAM for the Hibernate's second level cache or something like this, and the web layer box will be able to use it's RAM for JSP cache.

    Most of the time the choice to distribute is organizational, not technical. For example, two different independent groups -- one providing shared services, another doing web apps.
    Yet, in most cases the cost of RMI and other issues will make the overall system less per formant then if it was a collocated system.

    It's always less performant to separate web from EJB tier .. I've never seen an exception to this rule.
    I believe that Google for example uses distributed model in some form (kinda like all words starting with A will be stored in the cluster of boxes #1, all words starting with B will be stored in the cluster of boxes #2, and so on). To truly utilize this model though you need a very particular architecture that most aps do not have. An example of the this architecture would be for instance trying to emulate large, in memory database by caching it on a cluster of boxes where each box will handle a part of the database.

    It's called Tangosol Coherence. That's exactly what we do with our partitioned technology, and we've had it in production use at some very busy (100,000,000+ hits/day) web sites for years now.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  28. Questioning the principle of layering?[ Go to top ]

    Cameron,

    great post as always, cut to the bone and don't waste any flesh in the process :-)

    gentlemen, how can we spend so much time debating the sound, solid, and battle tested concept of layering your abstractions, this whole concept of "too much plumbing" and "too much coding" simply suggests you are a tad bit negligent on the work ethic front...

    the mother of all examples of why layering works is the bedrock technology that makes the serverside, our jobs as web app developers, and in fact, the Internet possible:

    TCP/IP

    if you don't understand why layering is a good idea, spend a quiet evening, open a bottle of wine, and crack open your old networking textbook from your computer science study days and re-familiarize.

    P.
  29. You probably missed a point[ Go to top ]

    If comunication and proccessing will be spanned by some number of machines model still be distributed, whenether it will be hidden distributed communication in clustered app server (or db server) or RMI remote calls. Still, all that is distributed
    processing. So physical location (near or far or in same room)
    just don't matter

    FLAME ON ;)
    There are too many anonymous.
    Change your nick name to real name, Victor Yanukovich.
    FLAME OFF
  30. You probably missed a point[ Go to top ]

    If comunication and proccessing will be spanned by some number of machines model still be distributed, whenether it will be hidden distributed communication in clustered app server (or db server) or RMI remote calls. Still, all that is distributedprocessing.

    I was addressing the point of EJB usefull-ness. EJBs are useful to implement apps with distributed deployment. Yet distributed deployment is never useful. If you need to invoke some lengthy external task, then usually you will be better off with messaging.
  31. TO LAYER OR NOT TO LAYER[ Go to top ]

    Believe me I have seen people forming start to end html pages in the SQL/Stored Procedure and advocating the same.

    The topic is much interesting and mostly seen being discussed among Java developers. Why we are discussing the topic?

    Ovious reason "not to layer" philosophy did not solve some of our purpose.


    CASE 1
    I worked in a mega project supporting the SOAP CLIENTS & WEB having (multiple oracle instances , main frame & DIBOL) backends as a developer. The application has 11 application layer and 5 architecture layer.

    A single use case touches more than 4 data sources if I can include LDAP as other data source. Each datasource has a different set of results formats and has to be merged before presentation. The way of fetching data from different sources is entirely different so as error handling / capacity planning. Response time of different sources are different.

    CASE 2
    Sometimes I recomend to use XSQL to form html/xml where there is no one between presentation layer and relational database.

    I strongly believe "layer / not to layer" question has to be answerd case by case not as general. APPLICATION LIFETIME / COMPLEXITY /COST OF DEVELOPEMENT and CHANGE REQUEST are few major parameter while answering.
  32. Piling on EJBs[ Go to top ]

    The bottom line is that a high-volume, transactional system is probably going to require what EJB has to offer.
    It's probably going to require what J2EE has to offer, not necessarily EJB. Most of the valuable services for building transactional systems, for example, relate to underlying things such as JTA: fundamental platform services, available also outside EJBs. EJB is essentially one component model that sits on top of J2EE services. You can get at them in other ways, which may be more elegant. We discuss this at length in J2EE without EJB.
  33. You're right.[ Go to top ]

    You're right, of course. I've been well-indoctrinated over the past five or six years. Of course, during the same period, a lot of ideas about the proper use of EJBs have shaken out, and with developements like ejbdoclet, deploying them is not the complete pain it used to be.

    Mind you, after reading a recent post about Ruby on Rails, I find my head being turned a little.
  34. Not the Architecture[ Go to top ]

    Java is not equal to J2EEJ2EE is not equal to EJB

    Agree.... I have seen more real unlayered (and mostly badly written) Java codes.

    And I'm sure there are many ways for you to build end-less layers of abstraction into your PHP/rube/whatever-scripting-languages-you-like

    Forget about requirements and architecture. These are all excuses. Most people just will not spend the times to think too much and end up with a masterpiece of mess.
  35. ....PHP's easy of use is nice at the beginning but eventually turns to be hard to maintain, test, scale, whatever hell.

    PHP can be organized though PHP community does not have any mature framework but a few of the PHP developers who likes well structured development they prefer some tools like Smarty(Like JSTL), ADODB(DAL), Pear DB(DAL) or some ORM like tools

    “FreeForm” is one of the well organized Frameworks for PHP5

    Whenever i checkedout RoR i really like RoR because of its clean separation...

    PHP community really wants some people who is really well organized and can contribute to develop such well structure framework rather than some experimental job… which will really a gr8 contribution for Enterprise PHP solution…

    http://hasan.we4tech.com
  36. Whenever i checkedout RoR i really like RoR because of its clean separation...

    My main dislike of RoR is its lack of clean separation. There is no separation between the data model and the database schema. Ruby code is required embedded in web pages.
  37. Layer, appropriately.[ Go to top ]

    Probably obvious and trivial but I'd put in at least enough layers to be able to test different components separately. I just couldn't bring myself to dump business logic inside a JSP or whatever the PHP equivalent is.

    The minimum on any non-throw-away application that needs persistence and some kind of ui should be three:

    presentation, logic, & persistence.

    Since any useful application tends to grow or be combined with other applications this minimum gives a starting point for inserting more layers as needed.

    I find appropriate separation brings a better design to my code, which brings easier testing, which brings easier maintenance, which brings....
  38. I would recommend looking at Martin Fowlers "Patterns of Enterprise Application Architecture" book. He puts forward several different type of application architectures with pros and cons of each architecture without getting into religous debates.

    From my point of view it is all about what the are the non functional requirements of the system. I personally tend to do two types of projects.

    First type are simple one of gigs building simple web sites. Generally very simple gigs with 2 of us working on it part time with no real maintence etc requirements. For this a simple PHP/JSP model 1 design with MySQL works just fine.

    The other type are my full time gigs which are large scale projects with me leading multiple (15+) developers (some off shore) on continous release cycles. Here is where good architecture layering is needed.
  39. I would recommend looking at Martin Fowlers "Patterns of Enterprise Application Architecture" book. He puts forward several different type of application architectures with pros and cons of each architecture without getting into religous debates.From my point of view it is all about what the are the non functional requirements of the system. I personally tend to do two types of projects. First type are simple one of gigs building simple web sites. Generally very simple gigs with 2 of us working on it part time with no real maintence etc requirements. For this a simple PHP/JSP model 1 design with MySQL works just fine. The other type are my full time gigs which are large scale projects with me leading multiple (15+) developers (some off shore) on continous release cycles. Here is where good architecture layering is needed.

    That's where I'm going to disagree. Even when I'm to only one, I use the same framework.

    Why? Reuse. Consistency. Proven working code. I just haven't seen anything that requires the PHP/Perl/ROR approach.
  40. So if you where doing a four page quiz site you would use the same framework/architecture as a full scale Enterprise deployment (Spring, Hibernate)?
  41. So if you where doing a four page quiz site you would use the same framework/architecture as a full scale Enterprise deployment (Spring, Hibernate)?

    Well I would. I already have the template for a web application that uses JSF+Spring+JDO. All the libraries are there, and I have web pages and config files from other applications that can be quickly tweaked for this one. This is actually a technique of development I learned a long time ago when I was a Smalltalk-er: Don't bother to write a new application when you can re-use parts of existing ones.

    After all, you never know when the four page quiz site will grown in to a 10 page site, or a 20 page site, or a site that has to run multiple quizes and collate the results.. and so on.
  42. "Don't bother to write a new application when you can re-use parts of existing ones"

    Well totally. But this doesn't mean JSF+Spring+JDO is correct for every application just becuase its what you have a template for. Just becuase you have this hammer does that mean everything is now a nail?

    I have several templates that I use depending on the clients non functional requirements. For instance a lot of part time work I do for non profits have a Non Functional requirement stating that the project is to be hosted on a HTTP/PHP/MySQL based ISP. I have a template built for this type of work.

    "After all, you never know when the four page quiz site will grown in to a 10 page site, or a 20 page site, or a site that has to run multiple quizes and collate the results.. and so on."

    You know I have sadly found I am terrible at guessing the future. Therefore I have decided as long as I don't close any doors and leave options for refactoring for furture requirements that is enough.
  43. "Don't bother to write a new application when you can re-use parts of existing ones" Well totally. But this doesn't mean JSF+Spring+JDO is correct for every application just becuase its what you have a template for. Just becuase you have this hammer does that mean everything is now a nail?

    Come on. That "hammer" quote is right there with "best tool". I(and Steve) have single java frameworks that scale up and down and can be used for projects large and small.

    You have at least two.

    If you want to add something to the smaller PHP, you cannot just use the code that is shared by the larger program.

    Your hammer anology doesn't fit because a hammer pull out nails and drive in nails. Java is a far more versatile. I mean, what exactly do you think are running in those Java phones? Where is the PHP-Micro Edition?

    Instead of support two(or more) frameworks for writing web-based applications, I'd rather have one that works for small web apps, large web apps, standalone java applications whatever.

    Now, to address the future...you are right. I can't guess either, so I use a single framework that can scale up instead of figuring how exactly you refactor PHP into Java!! :-)
  44. I think you keep failing to notice the words "non functional requirements" when you read my posts.

    "Your hammer anology doesn't fit because a hammer pull out nails and drive in nails. Java is a far more versatile. I mean, what exactly do you think are running in those Java phones? Where is the PHP-Micro Edition?"

    No but if you are in the phone/hand held development space you will know that J2ME is just one option and that you should also know what Brew is.

    "Now, to address the future...you are right. I can't guess either, so I use a single framework that can scale up instead of figuring how exactly you refactor PHP into Java!! :-) "

    Well easily. PHP is just a language like any other. Most simple PHP sites the design is a basic Model 1 design blah, blah, blah. You could argue this is a migration and I would say sure but migration and refactoring are not a whole world apart. As long as I can show I have not change the behavour of something before and after the change is that not refactoring?
  45. I think you keep failing to notice the words "non functional requirements" when you read my posts."Your hammer anology doesn't fit because a hammer pull out nails and drive in nails. Java is a far more versatile. I mean, what exactly do you think are running in those Java phones? Where is the PHP-Micro Edition?"No but if you are in the phone/hand held development space you will know that J2ME is just one option and that you should also know what Brew is. "Now, to address the future...you are right. I can't guess either, so I use a single framework that can scale up instead of figuring how exactly you refactor PHP into Java!! :-) "Well easily. PHP is just a language like any other. Most simple PHP sites the design is a basic Model 1 design blah, blah, blah. You could argue this is a migration and I would say sure but migration and refactoring are not a whole world apart. As long as I can show I have not change the behavour of something before and after the change is that not refactoring?

    I would call changing a PHP page with database access logic in it to a Struts page with database access behind a dao an architectural redesign not a refactor. But that's me.

    Ultimately, given a choice between using multiple frameworks based on the perceived complexity of a project, and one that reasonably fits projects of all complexity, I'll take the one.
  46. PHP is not a programming language[ Go to top ]

    It is just a scripting language.

    It is getting on my nerves, really. Would you please create an application in PHP for me that supports tens of millions of users of one type, and thousands more on a desktop application with hundreds conncurrently connected other type of users. We're doing this right now with Java. At least trying to pull it off... :)

    Now, where to layer? Where the intended layer adds value, or separates aspects of the applications, you should. On a previous project of ours, we had a layer that would have supported switching persistence from EJB to Hibernate easily, should EJB persistence fail to meet the our TPS (transaction/second) requirements. Now, we didn't need to switch, because EJB (cmp) performance was even better than expected (talking hunders of tables).
    In retrospect, that layer is unnecessary, but to this day, if we wanted Hibernate instead, we could just switch, without rewriting the whole persistence layer.

    Small projects don't need this kind of application infrastructure. But when and if they grow, they might. If they might, they will. Then PHP should just exit left, silently.
  47. PHP is not a programming language[ Go to top ]

    Small projects don't need this kind of application infrastructure. But when and if they grow, they might. If they might, they will. Then PHP should just exit left, silently.

    Even small projects benefit. That portal that I worked used Struts/Spring/Hibernate. The data on the main portal page was pulled from an external content management system. When I wanted to work on just the front-end, I changed one entry in the persistence.xml file to use a Mock class instead the real one. Now, the fake data loads quickly and I could spend time tweaking the look and feel of the page. It took me just under two days(1 to design/implement, 1 to test) to add OSCache caching support via a Spring-configured CacheAdmistrator and AOP advice.

    No changes to the data tier, no stuffing objects into session and now I have some base classes and interfaces that can be used on larger projects
  48. PHP is not a programming language[ Go to top ]

    It is just a scripting language.It is getting on my nerves, really. Would you please create an application in PHP for me that supports tens of millions of users of one type, and thousands more on a desktop application with hundreds conncurrently connected other type of users. We're doing this right now with Java. At least trying to pull it off... :)

    Well but it is not set in stone that the application that provides this support is written with the same technology than the one that supports the web interface is written in the same technology that does the thick client is written in the same language that supports handhelds and so on. PHP and, say Delphi, might still be excellent choices for the latter. While COBOL may provide your actual application and Java just do a bit of plumbing.....
  49. PHP is not a programming language[ Go to top ]

    In retrospect, that layer is unnecessary, but to this day, if we wanted Hibernate instead, we could just switch, without rewriting the whole persistence layer.Small projects don't need this kind of application infrastructure. But when and if they grow, they might. If they might, they will. Then PHP should just exit left, silently.

    My old boss had an interesting saying: "Never ever do anything just in case". I struggled with it quite a bit, because on the other hand, a lot of unexpected things just happen. But the question is:

    Are the things that happen the ones that you anticipated. I have long ago learned that things like "The database changed from Oracle to DB2" or "The persistence framework changed" hardly ever happen. And if they do, they are A LOT easier to handle than what usually moves: business requirements, deadlines, functionality...
  50. PHP is not a programming language[ Go to top ]

    I have long ago learned that things like "The database changed from Oracle to DB2" or "The persistence framework changed" hardly ever happen. And if they do, they are A LOT easier to handle than what usually moves: business requirements, deadlines, functionality...

    My personal experience is the exact opposite. Trying to deal with the software implications of a necessary database change can be a major and expensive exercise.

    And, of course, it may not be anything as simple as 'the database changed'. It may be 'we would like certain parts of the application to be available at another site that runs DB2', or it may be 'we would like some of our staff to be able to use parts of the application on their notebook PCs, and we don't want to have to buy them all Oracle licenses'.
  51. PHP is not a programming language[ Go to top ]

    My old boss had an interesting saying: "Never ever do anything just in case".
    Guess he never heard of that crazy stuff called insurance.
    I have long ago learned that things like "The database changed from Oracle to DB2" or "The persistence framework changed" hardly ever happen.
    Mostly cause it can't (or is very difficult and costly) be done - and not a lack of desire. The big database vendors LOVE this sort of thinking.
  52. After all, you never know when the four page quiz site will grown in to a 10 page site, or a 20 page site, or a site that has to run multiple quizes and collate the results.. and so on.
    And this happens more often than not. And usually most often. So building for reuse and reusing, as Steve has shown, is better than Q & D.

    I've done a few simple .Net apps (I've done others) where I used NHibernate with a VERY simple domain structure. Why? Cause I could get it done much quicker than plain ADO.Net. Much. And it wasn't a "web app". It was both a batch (the original) and a Desktop. Oldly, it was orignally supposed to be a batch. But when I realized that the people using it were, uh, easily confused by the command interface, I slapped on a Winform UI. I was able to do this becuase I spent the extra few minutes and separated out the code. Of course, it made testing much easier too.
  53. So if you where doing a four page quiz site you would use the same framework/architecture as a full scale Enterprise deployment (Spring, Hibernate)?

    That is exactly what I'm saying and doing. I had to create a three page portal. That was the project with the caching that I added. It uses the exact same framework code(based on Struts, Spring, and Hibernate) as two mid-sized projects. I haven't worked on any large projects in the past couple of years.

    If anyone wants to understand how our larger apps work, just look at the smaller one. The smaller app is smaller. It doesn't use a few Spring files that its larger sibling does: no security(yet), no notification(yet),for example. However, let's say that they want certain URLs disabled if you don't belong to a certain group. I can enable a Spring interceptor, create a appRole.xml file that defines what fields allow what groups. and that's it.

    That's all.

    Let's say they want to turn off the security. I flip a line in a taglibs.jsp from secure-html.tld to struts-html.tld(after all, turning-off is easier than turning-on, right?).

    I use the same base interfaces, base classes, exception handling scheme, etc...

    Both projects had to interface with the same external system. The smaller one(the portal) just had to read some data, but used basically the same code to do so.

    Why not? And we've seen the benefit. We lost a few people, gained a few, but they all cross-pollinate to most of the projects with an reasonably short ramp-up.
  54. I have learnt one simple rule regarding layers (don't remember where I read it):

    Less the layers, less flexible to change is the application.
    More the layers, longer it takes to make any change in the application.

    As with everything, we need to find the right balance based on the application requirements.
  55. More the layers, longer it takes to make any change in the application.

    I disagree with that statement. I think that layering speeds the time it takes to make changes. The reason being that you can find where to make the change quicker. I consider it to be analagous to good packaging. If you package classes correctly, you can easily find what to change and where. The key is keeping the layers pure.

    Plumbing between the layers can be a major problem, but can be overcome with a little thought and some reusable plumming code. Too often I find that developers don't take the time to make some good plumbing utilites and cause themselves some unnecessary pain. Aspect programming holds the promise of making these utilities even more powerful.

    John Murray
    Sobetech
  56. More the layers, longer it takes to make any change in the application.
    I disagree with that statement. I think that layering speeds the time it takes to make changes....

    I'm not saying that having less layers is better - but it certainly speeds up the rate at which changes can be made. For example, let's take a Model1 JSP application. Say I need to change some business logic. It's all in one JSP page - so it takes me a minute to change it, run it and test it. Now take a typical multi-tiered web application. The same change might require changes in the JSP, some Java Beans, some Action classes, some XML config files, some DAOs and maybe a Session Bean. Then I will need to redeploy the entire application and maybe even restart the Web/EJB server before I can run and test it. Now I'm not advocating using Model1 architecture, but don't you agree that the time taken to make a change increases as you increase the number of layers?
  57. Not Layers but components.[ Go to top ]

    Instead of looking at application system as layers we should look at it as set object interconnected together with clear responsibilities to achieve some busiiness goal.

    Layers come to picture when we start grouping these object by some metrics, usually these metrics are UI, data processing, back end integration or UI, network, database.
  58. Layer architecture is not an issue[ Go to top ]

    Layer architecture never been an issue for me.

    IMO, what we need to consider is what we should put in each layers and the flow b/w layers. Frameworks such as Struts, Spring, Hibernate help us to organise components in each layer while reducing our effort to develop and maintain non-functional code.

    Struture development oriented leads us to invent Layering Architecture + Frameworks

    my 0.02
  59. Eh?[ Go to top ]

    The author states:

    "At its simplest, maintaining a separation between presentation, business and data access seems to be the minimum degree of logical layering you should require in your system."

    Don't most of us agree on this one? So why does the post degrade into a mudball PHP example with business logic in the view layer? Please tell me that we as Java developers haven't forgot the days of the overuse of scriptlets in JSPs. Hell, with JSTL we could all go back to making the same mistakes and then some.

    Some of the 'core" J2EE patterns recommended by Sun can seem heavyweight for some projects. That's why architects need to use their noggin to prevent complicating things. But being overly simplistic is just as bad as being overly complicated in my books.
  60. Eh?[ Go to top ]

    Sorry it degraded a bit as I felt it was important to get the message across about being progmatic about things. It seemed to turn into a PHP bashing. I really do agree with what is said here.

    "At its simplest, maintaining a separation between presentation, business and data access seems to be the minimum degree of logical layering you should require in your system."

    95% of the time totally the way to go.

    "Please tell me that we as Java developers haven't forgot the days of the overuse of scriptlets in JSPs. Hell, with JSTL we could all go back to making the same mistakes and then some"

    No but I also can not forget the dot com days where a lot of people went the other way. Want a simple web site for a marketing POC? well you will need 10 higly skilled Java developers cranking out EJBs and you will need an mega $$ application server backed off Oracle.

    ;-)
  61. Language != Layering[ Go to top ]

    Layering is an architectural decision and is independant of language. You can do everything inside a Java scriptlet, or a PHP script, whatever.

    Layering does allow you a massive amount of flexibility when updating technologies. I had an app that was using entity beans. I was able to convert it completely to Hibernate very quickly. After creating the new Hibernate classes, I was able to integrate it with the rest of the system with a new plumbing class and a configuration file change.

    Then I was able to do Apples-Apples performance testing easily. All I had to do was change a single configuration XML to switch the application from Entity Beans to Hibernate.

    And for one more layering example. That same app was converted from Hibernate 2 to Hibernate 3 in 30 minutes. The system had over 50 tables controled by a dozen Hibernate specific classes. Layering isolated the code that needed to be updated and didn't force me to cull through hundred of code artifacts.

    John Murray
    Sobetech
  62. PHP and J2EE programmer experience[ Go to top ]

    PHP is getting complex, so many people are working on layering PHP. To layer or not to layer? the answer is To layer!!!