TSS Asks: Architecture - Web to Data Layer or Data to Web Layer

Discussions

News: TSS Asks: Architecture - Web to Data Layer or Data to Web Layer

  1. Even though I've never had the job title of "Architect," I find myself often working on designing business system using the typical three-tiered architecture. As three-tiered architecture has three layers consists of Web Layer(UI Tier), Service Layer(Domain Logic Tier) and Data Layer(Persistence Tier), at which layer do you start? There are supporters for each approach:
    1. From Web to Service to Data Layer
    2. Middle out, Service Layer
    3. From Data Layer to Web Layer
    Which way do you prefer and why? Thanks and Best regards, Chee Kin Message was edited by: joeo@enigmastation.com

    Threaded Messages (25)

  2. Here's the way I usually design applications: 1. Design screen mockups 2. Write Use Cases and System Integration Test Cases 3. Write a Functional Specification as described in "Joel on Software" At this point I have a clear understanding of what the user wants and know how I plan to implement the application. Then: 4. Using Test Driven Development, develop a clean domain model fully covered with Unit Tests 5. Develop the Infrastructure Layer, with as high coverage possible in integration tests. 6. Develop the Presentation and Application layers with as much test coverage as possible. 7. System Test and bug fix So, my method pretty much is top, middle, bottom, top. It works for me :)
  3. This what I do...[ Go to top ]

    a) Start with Use Cases b) Start with Screen Mock-Up a & b iterate for a while till baseline version is agreed among Tech. and Business Users c)Functional Specs is aggregation of a&b - all use case scenario and mock-up's - this document is sign-off point between Tech and Business d)Start Design - data modeling, Object modeling , Data Layer, Service Layer, and UI Layer step-d - everything is in parallel and there are several iterations among various interfaces. e) Unit Testing of each individual layer, followed with integration testing f) First release to internal QA g) Few iterations between QA team and Tech team h) Sign-off from internal QA team, publish first release to Business QA This has worked for me most time, however demography of developers and geographic locations do pose challenges from time to time but effective management have overcome those hurdles most of the time. Hope this helps Mittal
  4. Re: This what I do...[ Go to top ]

    Hi, Your way and Joel Schilling way is very similar, it is top-down approach. I believe it work great for large scale application development with large development team. Don't you think it is overkill(too much overhead) for small to medium scale application which developed by team of five members included QA and System Analyst? Best regards, Chee Kin -- Men are what their mothers made them. Ralph Waldo Emerson
  5. 1. High level use cases, for scope & basic concepts 2. Conceptual entity model 3. Activity diagrams, medium level use cases, case studies 4. Play the highlight nouns yellow, verbs orange game 5. Nouns: Hibernate mappings, gen an object model, DB, DAOs 6. Verbs: ID services & map model to services 7. Take one service and detail business actions 8. ID UI flow around one service from activity diagrams. 9. Pick one flow and code service, business logic for it 10. Mock up screens for the flow and connect to the service 11. Iterate by going back to 6,7,8 until release possible 12. Tailor gen'd DB schema with tablespaces, indexes etc... 13. Profile and tune Any following step can add tweaks back to step 5. I really like writing Hibernate Mappings as the first artifact and generating everything else. This works until I deploy and get production data, after which large schema changes require data migrations, so generating them isn't very useful. Can somebody tell me how you can possible do UI before the object model? Generally UI is making CRUD pretty. If you have no object model, you don't know what you need to do CRUD on.
  6. +1 (roughly) Projects usually start with requirements/specifications in informal language, using non standardized terms for all the concepts (both data and processes) in the problem domain.
    In the perfect world (!) one would analyse the original reqs/specs, elaborate and rewrite them, let the customer agree (…) and then start your designs using the standardized terms only.
    Using the “Program to an interface, not an implementation” pattern, you can give your project a jump start (and scale up easily) by first writing your types as (initially possible “empty”) interfaces and then creating your services and test cases, using the previously created types as parameter / result types.
    In large projects, take care of a proper subproject / module / package structure (internal application architecture) for optimal maintainability!
    When your domain model and (application)process / dialog model have reached sufficient level of detail, you can finish your screen designs and other external interfaces (create a separate adapter for each visible external system).
    A tip for large domain models: split them up into simple type / complex type and business concept packages. Use Borland Together to quickly generate insightful graphical models of your domain at various levels!
    I really like the DDD principles , an MDA approach using a flexible metadata repository (have a look at Protégé), would be a great help in large / complex projects, especially if you manage to integrate the contents of your repository in your documentation (I am currently looking at ways to integrate Protégé repositories in XWiki).
    Happy developing, Rob.
  7. Code generation from bottom to top is a common pattern among tools out there. Has anyone done anything with code generation top->bottom? I'd like to eventually develop something in AppFuse that reads from a view page and generates the data layer. I imagine a lot of designer-types would use it, but don't know if it would be useful beyond that.
  8. Hi Matt, I am learning and evaluating AppFuse 2.0 recently. Thanks for your great efforts to ease the pain of kickoff Java Enterprise Application Development.
    Code generation from bottom to top is a common pattern among tools out there. Has anyone done anything with code generation top->bottom? I'd like to eventually develop something in AppFuse that reads from a view page and generates the data layer. I imagine a lot of designer-types would use it, but don't know if it would be useful beyond that.
    IMO, I think the approach taken by Naked Objects(www.nakedobjects.org) is better, generate UI from Domain Model which allowed for customization later is better as Web UI consists of CSS, JavaScript and HTML, It will be very complex for complex data entry form, eg: modern ERP. Keep up your great works as usual! Best regards, Chee Kin
  9. Obviously I always start with the use cases, but where to go next really depends on the nature of the application. If it's a typical web application starting from scratch, the UI is the closest thing to realize the use cases, so UI -> domain model -> services/schema fall into place. On the other hand, if the application needs to not only support UI, but also, say, to expose a Web services interface, may the better starting point is the domain model/service layer, which tends to become the center piece and sort of the "clearing house". Lastly, if it's an enterprise integration project, where I'm looking at existing data repositories to work with, then naturally that's where the anchor is set.
  10. Bottom-up is the one for me[ Go to top ]

    The bottom-up approach is usually the one for me. Reason being quite simple, data is the core for any application. Any application developed/used manipulates the data. It is easier to manipulate data from front end(Web Applications or tools) when the PDM (Physical Data Model) maintains integrity and consistency. Of course integrity can be checked via front end (Web Application) but consider a scenario where external tools are also accessing the data concurrently. More sound a PDM (Physical Data Model) is, the easier it is to perform CRUD operation without losing data integrity or consistency.
  11. Re: Bottom-up is the one for me[ Go to top ]

    The bottom-up approach is usually the one for me.
    Reason being quite simple, data is the core for any application. Any application developed/used manipulates the data. It is easier to manipulate data from front end(Web Applications or tools) when the PDM (Physical Data Model) maintains integrity and consistency.
    Of course integrity can be checked via front end (Web Application) but consider a scenario where external tools are also accessing the data concurrently.
    More sound a PDM (Physical Data Model) is, the easier it is to perform CRUD operation without losing data integrity or consistency.
    Do you look into AppFuse and Apache OFBiz? They are using Bottom-Up approach as far as I know. May I know do you have any comment to these two projects? Regards, Chee Kin -- Performance is easier to add than clarity.
  12. related question[ Go to top ]

    whats the best approach for following situations 1. carry data from web layer(html forms etc) into domain model. 2. domain model to showing it on html pages to customers. this may involve object to object mappings etc. but are they easy to manage ? anyone dealt it with big domain models and large forms that it goes out of hand to know which html data goes into which domain model object. ? Great if you could share your ideas, experience.
  13. Re: related question[ Go to top ]

    whats the best approach for following situations
    1. carry data from web layer(html forms etc) into domain model.
    2. domain model to showing it on html pages to customers.

    this may involve object to object mappings etc. but are they easy to manage ? anyone dealt it with big domain models and large forms that it goes out of hand to know which html data goes into which domain model object. ?
    Great if you could share your ideas, experience.
    Yes. I mentioned this for the same discussion in JavaLobby too. Data Entry Form, Listing Screen and Reports are rarely fit with the domain model, which I called "UI and Domain Model mismatch", I would like to know how others resolve this problem? Regards, Chee Kin -- People who do the world's real work don't usually wear neckties.
  14. UI and Domain Model mismatch[ Go to top ]

    Yes. I mentioned this for the same discussion in JavaLobby too. Data Entry Form, Listing Screen and Reports are rarely fit with the domain model, which I called "UI and Domain Model mismatch", I would like to know how others resolve this problem
    IMHO there is no such mismatch, there is a misconception that they should match...
    This is why "generate an application based on your database" leads to quick but generally unusable results.
    Design a service layer around your domain model and generate your UI based on this service layer, this will yield a much more usable UI. Rob.
  15. Depends on the system. If its a small quicky with a short lifecycle, then begin with the UI. If it is a large system with long lifecycle or even a software product, then start with the data layer or possibly the domain layer. The data layer is the layer which it is least likelly that you will be able to change after the first release, so it is important to get it right. It is also the layer that has the biggest impact on the other layers.
  16. UCD[ Go to top ]

    The most usable systems (IMHO) are those that are usecase-oriented. So start with the UCs, realizing them with UI mockups, for the client's benefit. When client & you are satisfied, develop services and supporting domain model. Start with services, since these should drop naturally out of the UCs, but the domain model should emerge pretty quickly and overlap with service development. Too much Railsesque bottom-up stuff may be fun for the programmer, but IMO, for all but the most basic of CRUD functionality, it leads to unfriendly UIs. Kit
  17. Re: UCD[ Go to top ]

    ...but for writing down your use cases, you will use nouns and verbs. For consistent use case descriptions, you will need to establish a project-dictionary describing the nouns and verbs to be used and their meanings. For consistent logic in your use case descriptions, you have to have a clue about the relations between the business concepts. Ah, this is what they call a domain model. I stick with it: start with the domain model, although it will not need to be detailed to the lowest level from the start. Allow it to grow and gain detail according to your project settings. Rob.
  18. Re: UCD[ Go to top ]

    ...but for writing down your use cases, you will use nouns and verbs. For consistent use case descriptions, you will need to establish a project-dictionary describing the nouns and verbs to be used and their meanings. For consistent logic in your use case descriptions, you have to have a clue about the relations between the business concepts. Ah, this is what they call a domain model. I stick with it: start with the domain model, although it will not need to be detailed to the lowest level from the start. Allow it to grow and gain detail according to your project settings.

    Rob.
    You will do all that, probably. However, a UC can be realised with a transaction script as much as by an OO domain model. The domain model is the means to an end, the end being the UC.
  19. Re: UCD[ Go to top ]

    The domain model is the means to an end, the end being the UC.
    Agree. The domain model is the start, not the end. The foundation of the "building", not the "windows". It's the language, not the story. See "Ubiquitous Language". Rob.
  20. Ineresting question. I think there are books on this subject. Rails in my opinion is built for development speed and leads to physically flat and somewhat logically tiered apps. Microsoft is the same way. In the end it depends on lots of things. What is your current methodology - does it already do it one way. RUP is iterative and incremental where you start with use cases and go to analysis classes on down to objects etc.. Agile seems to rely on each developer's skill and need for poetic license. "Gett'r done" with tests. The composition of your team may determine your approach. You may have a HTML jockey, a service/BO/session facade jockey, and a DBA (table jockey) designing their own tiers interfaces and implementations. This can suck because of the politics and inefficiency. If you get an alpha dog or a passive agressive in any tier this tends to drive whether you are data driven or behavior driven. If it is one architect/designer/developer working on a database-backed web app then my approach is usually. Read requirements Know your stack - target architectural components Define high level use cases Assign responsibilities to packages (systems) Produce analysis model of stereotyped objects, collaborations, interfaces Refine to object model Cut first data model to get to data dictionary At this point you have a business and domain object api needed as input to web app design. One can mock out business or domain to get to web app protoype. Web apps are the least reusable component, require the most change management usually for usablity sake, and have the most dependncies and are ultimately the most disposable component. If you think like a web app, walk like a web app and behave like a web app, you tend to miss the boat on producing reusable cohesive services that map well to database subject areas. Stick to objects, interfaces and patterns - DAO and Session facade particularly. Spring is a great tool for facilitating and enforcing this and making you code higly testable. Support logical tiers that can be physically flat but extensible to physical tiers. Alas you don't start in the top middle or bottom. You do it all and as you realize each use case the model, the design, and the strategy present themselves. Word to Rebecca Wirfs-Brock/Alan McKean and Craig Larman for writing great books on this stuff.
  21. Outside in[ Go to top ]

    From what I've seen in the end clients usually are interested in three things: the user interface, the business rules, and the data. How you get there can vary depending on the requirements gathering process. As far as architecture I've done 1, 2, and 3 and even done MDA code generation in various directions. But what I found best is doing 4. Outside in. That is web and data in parallel and then work your way to the middle or the service layer. Why? This guarantees that the client is happy with the user interface and the DBA is happy because the schema has been designed with data in mind and not via domain objects. I've already seen too many projects at my company that have generated a database schema from objects or from an ORM, that then have to be completely redesigned once your start performance testing.
  22. Re: Outside in[ Go to top ]

    From what I've seen in the end clients usually are interested in three things: the user interface, the business rules, and the data. How you get there can vary depending on the requirements gathering process.

    As far as architecture I've done 1, 2, and 3 and even done MDA code generation in various directions. But what I found best is doing
    4. Outside in.
    Yes. I fully agreed that the outside-in approach is the best. We should work closely to customer/user, their needs should place the highest priority. What is your opinion for best approach of outside-in, iterative and incremental process for use cases->screen mock-up->domain model?
    That is web and data in parallel and then work your way to the middle or the service layer. Why? This guarantees that the client is happy with the user interface and the DBA is happy because the schema has been designed with data in mind and not via domain objects.
    As you said you work with MDA code generation before, where is the domain model come into picture? May I know your views to DDD (http://domaindrivendesign.org/)?
    I've already seen too many projects at my company that have generated a database schema from objects or from an ORM, that then have to be completely redesigned once your start performance testing.
    May I know which ORM do your company used, Hibernate? Best regards, Chee Kin -- If you wish to be a sucess in the world, promise everything, deliver nothing. Napoleon Bonaparte
  23. Folks, you are all describing design, not architecture. This is not an architecture issue at all. Architecture issues in this case involve defining your tiers and layers, interfaces and roles not in an application specific way but in terms of patterns and standard you will follow.
  24. Folks, you are all describing design, not architecture. This is not an architecture issue at all. Architecture issues in this case involve defining your tiers and layers, interfaces and roles not in an application specific way but in terms of patterns and standard you will follow.
    Dude, do a dice.com search for designers. The title architect is a chick magnet! I agree that the question is not really about architecture or even design but methodology. But really, how much of an architect's time is spent chosing between Microsoft, Java or LAMP and whether the system should use pipes and filter, tiers, or SOA. I would argue that "architecture" is a blend of architecture, design, and development in today's usage so the original question is meaningful.
  25. But really, how much of an architect's time is spent chosing between Microsoft, Java or LAMP and whether the system should use pipes and filter, tiers, or SOA. I would argue that "architecture" is a blend of architecture, design, and development in today's usage so the original question is meaningful.
    Well, I am an architect and I spend a lot of time dealing with the architecture concerns to which you refer. You are right about the title being thrown around because it has prestige and marketability, but a lot of folks with the title "architect" are really tech leads/lead engineers/lead designers. It is also true that the boundary between architecture and design is not always clear cut, but this question starts well within the design phase where you’re working with the user’s specific requirements. As the post implies, the decision to go 3-tier was already made. That was an architecture decision. The questions about whether to be web-based and whether to use servlets, JSP, ASP, CGI were architecture decisions. The questions about where to put the business logic, data domain logic, and presentation logic are architecture. In this case the post is assuming those decisions are already made and we are designing the code – screens, tables, business logic we will implement. That is not architecture. The difference here is between “how” and “what”. Of course many of us legitimate architects were developers and continue to do development in part to keep our knowledge current and relevant, because we enjoy it and/or because those skills are what is needed at the time. But architecture is not defined as everything someone with an architect title does. I had a dentist who mowed his own lawns and did his own payroll. Bookkeeping and lawn maintenance are not dentistry.
  26. Hi, Thanks for your fast response. For your information, I had posted the same discussion to JavaLobby, you may interest to visit there: http://www.javalobby.org/java/forums/t92917.html Happy Weekend! Best regards, Chee Kin -- The imbecility of men is always inviting the impudence of power. Ralph Waldo Emerson