Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In web frameworks like ruby on rails, any database queries needed to handle a specific request happen before a page is passed to the client in a controller class, but there’s nothing like that for clojure. Where should database queries and stuff like that be handled in a clojure web app? My gut tells me to call a function within a hiccup page and generate the HTML within that function, but I’m not really sure. Thank you for your time and consideration.
There aren’t that many “full stack” web frameworks in Clojure and as far as I know most Clojure web applications aren’t built with one. There is a collection of frameworks and tools that handle a variety of things, but you’ll likely develop your application using these components as building blocks. You have a choice of routing functions, authentication, view rendering, templating, RESTful web services and persistence.
Where particular things should go in your application depends on your architecture – a typical, 3-tier MVC web application looks different from a full blown scalable app that’s using CQRS, CEP and other fancy patterns that help you build the next Facebook or Twitter.
If you design your web app conceptually with a 3-tier MVC architecture in mind, you’ll have a clear separation between your view layer, business logic, and persistence layer. Like Alex said in his answer – it’s probably the Controller that ties these things together. If you don’t have complex business logic, your controller will likely call functions from your persistence layer directly before passing it on to the logic that builds your views.
For some situations, it might be useful to pull in data from your persistence layer in a “middleware” — that is a function that gets called by Ring every time a request comes in. This could be the stored information about a logged in user for example.