Java EE - What is the correct layer for formatting domain model objects before passing them to views?
Asked Answered
S

1

2

I am developing a web application which has a typical layered architecture:

a DAO layer that retrieves domain model objects from a database;

this layer communicates with the service layer which does some business operations using those objects;

the web layer (Spring Controllers) use the service layer to retrieve the domain model objects (or collections for them) and pass them to the view layer;

the view layer is either simple JSPs which show the data using JSTL, or JSPs which retrieve some of the data through AJAX in the form of JSON objects (domain objects converted to JSON through Jackson library).

I have been researching about the following:

Very often I need to convert the db fields to a different format to show to the user. For example, a Date might be store as a Timestamp and I want it to show it as a formatted date (e.g. dd/mm/yyyy).

Also, I need to do the opposite, convert some value (usually user input) to the format of a domain model object's property.

My question is, where should I be doing this kind of conversions? Especially with JSON data, they should be already formatted on the AJAX response, I dont think I should format it with Javascript, am I right?

Thank you in advance.

Sandblast answered 13/7, 2011 at 20:14 Comment(0)
S
2

Very often I need to convert the db fields to a different format to show to the user. For example, a Date might be store as a Timestamp and I want it to show it as a formatted date (e.g. dd/mm/yyyy).

Also, I need to do the opposite, convert some value (usually user input) to the format of a domain model object's property.

My question is, where should I be doing this kind of conversions?

My opinion is that all data format conversions ought to be done in the view, or in collaborative objects. The model or the service layer should not be performing this activity. It would be poor design to perform this in the model, for it would couple the interfaces exposed by the model to only one view. Also, it would make it more difficult to make changes in the view, requiring changes in your model as well.

You can refer to well-written JSF applications (since you mentioned that you are using Java EE), where specific converters are written to ensure that the view would format the contents of the domain objects appropriately.

Especially with JSON data, they should be already formatted on the AJAX response, I dont think I should format it with Javascript, am I right?

That would depend on how you view the view. If your representation of the view is that the server must provide the client with formatted data, then the server ought to do this. But, most applications take the practical approach where in client-side logic is also treated as part of the view. Depending on the context in which the data is used, you may:

  • either format the data on the server, especially if the formatted data is used universally at the client side without any further modifications.
  • or, transmit data to the client in a canonical form, which is then formatted on the context in which the data used and/or is displayed to the user.
Slogan answered 14/7, 2011 at 1:21 Comment(19)
I have never used JSF and I have read many negative things about it so I would not like to go there at the moment. You mentioned "collaborative objects", what do you mean by that? Some kind of DTOs that contain the formatted data to show to the view? This might be a good practice, but it might be an overkill ,adding new classes for every domain model class that you need to show to the view. I mentioned as a bad idea the Javascript formatting because I know that maintaining it (or in my case jQuery) is a nightmare. But if I understand correctly you are not against it?Sandblast
If the view class itself doesn't format the data, but instead delegates it to a converter to do the same, then you are using a collaborator for formatting. A simpler example would be the c:out tag in JSTL, which performs XML encoding of the data before writing it to output. On the topic of sending encoded data from the model to the views, I would consider it a bad practice. What if you need to add a different client tomorrow - perhaps a thick client or a web-service? What would you do then? Creating separate DTOs or domain classes for each form of encoding is IMHO poor design.Slogan
I am sorry if I sound confused but I am not sure if I understand. In short, your opinion is that the formatting should be done on the client, either JSTL, or Javascript. Am I correct? Also, the c:out tag that you mention, how is it independent of the view? It is declared inside the view, isn't it? So, to conclude, in my case where most of the data comes from AJAX calls, all formatting of the data should be done in Javascript?Sandblast
@alex, JSTL runs on the server. The c:out tag is not independent of the view. It is independent of the model, and allows the model to not bother about encoding. As far as formatting of data is concerned, my opinion is that you should do it in the "view". It can be browser-side JavaScript, or server-side routines depending on what is suitable. That's what I meant by the phrase - Depending on the context in which the data is used. You may do the formatting in two different tiers, but for practical purposes, consider that there is only 1 view in your application.Slogan
Just to clarify one last thing, when there user input, the conversion to db fields should also be done in Javascript? So the data is converted first and then sent to the server?Sandblast
@alex, no, I don't think that would be a good practice. I believe you are assuming the view to be strictly JavaScript whereas I am assuming the contrary. The server in this case, is a separate tier, and the view component (JSP/Servlet/Facelet and hosted JS) in it should be the one that coordinates with the model (the EJB/DAO responsible for communication with the DB). It would be preferable to have the view perform a first-level of validation, but the model or view helper classes should be responsible for the conversion. This would dictated by the model's interfaces. Contd.Slogan
In an ideal scenario, your model would be dictating the format of the data it should be receiving, performing any necessary validations including business validations, process the data, and persist it. The view should be the component that performs any conversion of client provided data to the one expected by the model. The view may accept the same format of the data from the client, as defined by the model (but this is not possible in systems, beyond simple CRUD interfaces). In simpler words, your system should have well-defined data/message-exchange formats across layers (MVC) and tiers.Slogan
Continuing from above, it would therefore be wise to choose JSON as a message exchange scheme for view components that are better suited to use JSON, and use other formats (simple HTTP POST) for other view components. All of these views would then perform any validation and conversion before communicating with the model, which would again perform validation (against a canonicalized set of messages).Slogan
I would like to leave validation aside for now, it seems to complicate the discussion. Let's talk about data conversion. I will be very specific this time. I have a data grid populated from a database. the data from the server to the view is passed in JSON format. Where do I convert the db data to the view format? After that, the user might make some change, or filter the data through a text field. the user data is passed to the server again in JSON format. This time, where do I make the conversion from the user input format to the db format?Sandblast
Where do I convert the db data to the view format? That would be in the view (on the server) and nowhere else; only the view should have this info to transform the data represented in the domain model, to one required by the client/browser/user. After that, the user might make some change, or filter the data through a text field...This time, where do I make the conversion from the user input format Again, it would be in the view. You can have an intermediate encoding (like URL encoding) to ensure that the user provided data will arrive at the server, where it will be converted.Slogan
OK, this is very clear, thank you! so, since it is JSON, everything is done in Javascript. Which, if we are talking about a lot of db tables and fields to be converted (and of course many type of conversions) a considerable amount of Javascript. Which makes the maintenance harder. But you seem certain for your answer, so I would not argue anymore. Again thanks a lot for your time!Sandblast
@alex, I haven't seen your JSON format, but it is not necessary for your JSON messages to contain the database structure, and in fact it shouldn't (for reasons starting with security, and also covering maintainability). That's why you would define the format of the messages between the browser and the view on the server, and the view and the model. Otherwise, you would end up in the scenario where a change in the data/object model would result in a change in the JSON format; this is what MVC was meant to prevent in the first place.Slogan
In your previous message you mention that the convertion is done on the view. What does view means in the case of JSON communication? It seems we have a different understanding on that. I have an initial jsp page, which makes ajax calls (JSON data) to get the data. These calls are handled by servlets. The servlets call methods from the service layer that in turn call methods of the dao layer. What is the view for you in this case? Isn't it the JSP - Javascript part? Where is the data conversion made? Am I really that ignorant, not understanding what you are saying?Sandblast
I've got more clarity now on how you are building your system with your last comment. The JSP-JavaScript part is the view in your case, and I would consider the Servlets would be the controller or the model, depending on their responsibilities, and whether other classes serve to act as the model. W.r.t. to data conversion in your case, I believe you would be better suited by performing this in your classes associated with the model that receive and parse JSON data, or send data back in a JSON format. Contd.Slogan
The conversion ought to be done before you apply the request data value to your model, or before you prepare the response. I would consider it premature to perform the conversion completely in JavaScript in either of the phases (request-processing or response-preparation). This is different from my earlier advice in that the view should perform the conversion, as I assumed the presence of more than JSP page that rendered the base view with JSON being used for partial updates; that model no longer holds good here.Slogan
So in this case you say no conversion in model classes and no conversion in Javascript. The thing is ,the intermediate between those to is the service layer. You suggest to make the conversion in the service layer classes? Because there are no other classes between the view an the model (exept for the servlets of course)Sandblast
Honestly, I'm beginning to struggle here, in understanding the finer nuances of your design. Both of us can agree on one thing here - I've stated that the conversion must happen on the server side instead of JavaScript. I don't know how your service and persistence layers are designed, how your Servlets are written, and what conversions ought to be done. You could post a new question with these details, or even drop in a mail. I suspect a chat session might not give you enough time to convey this.Slogan
This is still my original question, if you read it again I describe the architecture. I am not sure why I should start a new question. It is more or less as described here: blog.codebeach.com/2008/06/…. I will like to move this to email, but where do I find your email address?Sandblast
just a heads up, i did sent you an email yesterdaySandblast

© 2022 - 2024 — McMap. All rights reserved.