> And how would one structure something as stateful as a web app using these > techniques? Hopefully someone can point to a pre-existing example that > follows all or many of these ideas.
I currently work on a thick-client system. But our back-end is quite stateless. One thing that irks me the most about our system in C# is that we've intertwined business logic with business data. So, in our application, let's say we have a person class. We will have the following classes: tPerson (data class generated by our ORM) PersonDTO (data transfer object) Person (business object) So the idea is that SQL will load data from the tPerson table and place it into a tPerson C# object. Now, the last thing we want, is to have a hard dependency on tPerson from our Person object. that is, we never want to have Person take tPerson as an argument. Because then those two objects are tightly coupled. Where one goes, the other must follow. So instead we have a PersonDTO object that transfers the data between the objects. The Person object the contains business logic (user must have a last name...user must be over 18, etc.). The sad thing is, that business logic is now built directly into Person. This complicates the whole system. What Rich is advocating is this: throw all the data into a hashmap. Suddenly, my SQL driver can just dump data in to the map, I can throw that map around without introducing dependencies, and I can pass that map through the web to the client. In addition to all this, I should break my rules out of the Person object and into a set of validator functions. Now I have real power! Suddenly my rules apply to any and every object that has a last name property and a age property! So instead of 3 tightly coupled objects, I will be left with a map, and a set of highly generic functions that can be reused again and again. Getting back to your question, I think it's just good to sit down with your web app and start asking yourself. "What assumptions am I making about this code? Am I assuming function a will always call function b? Could there be a case where I would want a to call c? Well in that case, maybe I should account for that...". The SQLObject->DTO->BusinessObject pattern is fairly common in the real world. So perhaps that is something to re-evaluate in your designs. Timothy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
