I want to start a new project and I just got in touch with Play framework, which has a ruby on rails -like approach that called my attention. I am not an expert in rails, but I think that the productivity in these frameworks are great.

I am following some tutorials but I am wondering: Play has the Model, which is used to populate the view but also used to perform DB queries. I find that somehow awkward, but I noticed that rails has also this approach.

I wonder if using the same entity for Object Relational Mapping and to populate the view may cause troubles. Here are two examples I can think of:

  • My view required only a name and an ID from a big entity
  • My view requires information from different entities

For the second case, I suppose I would be able to perform a join. But it seems somehow messy: joins in my controller, DB entities being used to populate views.

Am I missing some point here? I mean, these frameworks seem great and I would like to use them, but I wonder if my code wound turn into an spaghetti code. It seems to be on the opposing direction of I learned about separation of concerns.

If I separate in a layered architecture (models for my views, business logic layer and DAO layers), should I keep using play or should I move to something different like Spring?


It doesn't have to lead to confused code, but there are trade-offs. Sometimes you may find that your ORM is pulling all the fields of data from a row when you only need two, sometimes the queries would not be the same as those you would use or you may need to get a greater depth of entities than the ORM will automatically query so you end up going back to the database a couple of times when perhaps you could theoretically have got all that information in one trip.

These types of thing are standard outcomes of using an ORM system and aren't tied specifically to any particular platform.

The question you need to ask yourself is really about that balance and consequently about what you feel is important:

  • Do you want to write very detailed code, or get code written quickly?
  • Do you want to save your processor time, or do you want to save yourself time?
  • Would it be better value to use a more powerful server, or to spend longer writing code in the first place?

When it comes to MVC as opposed to MV-VM-C, that again comes down to personal choice- in MVC settings I have seen logic in models that possibly didn't theoretically belong there, in cases where ViewModels are used, I have seen totally redundant empty classes being created just to ensure that every model had a corresponding ViewModel even when neither had any discernable logic in them.

The important thing is that before you choose a platform, you read up on its advantages and disadvantages and when you make your choice, you learn to use it in a way that means you can write code that fits with the ethos of the platform and that you ( and other developers ) will be able to read in future. Honestly that is more important than whether the platform you are using is an ideal implementation of a specific design pattern or a currently fashionable twist on it. I mean I know people who write good code in PHP - sometimes it's important to look at the bigger picture. And lets not forget that design patterns themselves are more like guidelines than actual rules.

  • Yes, your points are valid. I just don't want to spend some time coding things and get with a confusing code that is hard to maintiain after some time (and then wasting more time getting around my code that implementing new things) – JSBach Sep 3 '14 at 17:13
  • The way to frontload this is actually to do some prototyping/playing around with the platform before you start, so that you know that it does the things you need and get the basics of it's idioms. That saves a lot of time in the long run. My experience with Rails has been that there is no maintainability problem with models and model code, the real problems arise from depending on gems that are subsequently deprecated/abandoned- after a while that starts locking you to old versions of everything. – glenatron Sep 3 '14 at 17:26
  • Interesting point. I have a very limited experience with rails, but I really liked the language. The similarity to rails caught my attention in Play framework. I am starting the research now. I will make some prototypes to see it in action, thanks :) – JSBach Sep 5 '14 at 16:21

Your concerns are valid.

Default pattern of Rails-like frameworks are great for small(er) programs coded by less-experienced programmers that don't have a grasp on software architecture -- framework provides a skeleton for the whole application, all abstractions are defined, after coding 3 classes we have something on the screen. This use case is also good for prototyping.

It doesn't mean that framework of this kind can't be used when doing more serious software development - it can (and probably should), but more as a tool than as main structure of the program.

Decoupling business objects from the view is certainly a good habit. I'm sure it can be done as easily when using Play framework as it is with Spring. You can check out Robert Martin's Keynote to Ruby Midwest 2011, where he presents an architecture that completely decouples business logic from the framework (or "delivery mechanism", as he calls it). He uses Rails as an example.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.