Mixing
Should a POJO be connected to a view or controller?
I am working on a Spring project where the overall structure is based on the view-controller-service-layer-DAO/POJO layout.
I am working on a new POJO object and am unsure of where the best place to bind it would be. The two that make the most sense to me is putting it into the view where it is being used, or the controller which appends it to the view as it would other pieces of data.
The one view has a table which displays multiple kinds of similar data. The table shows the data name, the counts of changes for new, modified, and deleted, pieces of data (which can be drilled down into), and finally the total number of changes.
Since I am expecting to maintain this software myself in the future I have tried to make it expandable and easy to maintain. As the project requires bilingual pages I am heavily using the spring messaging feature. So my new object accepts 5 parameters. The first four parameters are strings, the field name spring messaging key, the drill page header spring messaging key, a database stored procedure name for the counts, and database stored procedure name for drill page values. The last parameter is an array list of strings which are spring messaging keys for the column headers on the drill page.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The way I built the new POJO does break the v-c-s-d model that is being used for the project, but I did not want to create additional project files to interact with an object that is only being used to display in that one table, and to drill into results from that table. If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful. But in this case, the POJO is largely self-contained as it has a tightly coupled DOA for its own database calls.
java spring spring-mvc pojo
edited Jan 2 at 19:18
Nikolas
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
add a comment |
I am working on a Spring project where the overall structure is based on the view-controller-service-layer-DAO/POJO layout.
I am working on a new POJO object and am unsure of where the best place to bind it would be. The two that make the most sense to me is putting it into the view where it is being used, or the controller which appends it to the view as it would other pieces of data.
The one view has a table which displays multiple kinds of similar data. The table shows the data name, the counts of changes for new, modified, and deleted, pieces of data (which can be drilled down into), and finally the total number of changes.
Since I am expecting to maintain this software myself in the future I have tried to make it expandable and easy to maintain. As the project requires bilingual pages I am heavily using the spring messaging feature. So my new object accepts 5 parameters. The first four parameters are strings, the field name spring messaging key, the drill page header spring messaging key, a database stored procedure name for the counts, and database stored procedure name for drill page values. The last parameter is an array list of strings which are spring messaging keys for the column headers on the drill page.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The way I built the new POJO does break the v-c-s-d model that is being used for the project, but I did not want to create additional project files to interact with an object that is only being used to display in that one table, and to drill into results from that table. If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful. But in this case, the POJO is largely self-contained as it has a tightly coupled DOA for its own database calls.
java spring spring-mvc pojo
edited Jan 2 at 19:18
Nikolas
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
add a comment |
I am working on a Spring project where the overall structure is based on the view-controller-service-layer-DAO/POJO layout.
I am working on a new POJO object and am unsure of where the best place to bind it would be. The two that make the most sense to me is putting it into the view where it is being used, or the controller which appends it to the view as it would other pieces of data.
The one view has a table which displays multiple kinds of similar data. The table shows the data name, the counts of changes for new, modified, and deleted, pieces of data (which can be drilled down into), and finally the total number of changes.
Since I am expecting to maintain this software myself in the future I have tried to make it expandable and easy to maintain. As the project requires bilingual pages I am heavily using the spring messaging feature. So my new object accepts 5 parameters. The first four parameters are strings, the field name spring messaging key, the drill page header spring messaging key, a database stored procedure name for the counts, and database stored procedure name for drill page values. The last parameter is an array list of strings which are spring messaging keys for the column headers on the drill page.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The way I built the new POJO does break the v-c-s-d model that is being used for the project, but I did not want to create additional project files to interact with an object that is only being used to display in that one table, and to drill into results from that table. If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful. But in this case, the POJO is largely self-contained as it has a tightly coupled DOA for its own database calls.
java spring spring-mvc pojo
edited Jan 2 at 19:18
Nikolas
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
I am working on a Spring project where the overall structure is based on the view-controller-service-layer-DAO/POJO layout.
I am working on a new POJO object and am unsure of where the best place to bind it would be. The two that make the most sense to me is putting it into the view where it is being used, or the controller which appends it to the view as it would other pieces of data.
The one view has a table which displays multiple kinds of similar data. The table shows the data name, the counts of changes for new, modified, and deleted, pieces of data (which can be drilled down into), and finally the total number of changes.
Since I am expecting to maintain this software myself in the future I have tried to make it expandable and easy to maintain. As the project requires bilingual pages I am heavily using the spring messaging feature. So my new object accepts 5 parameters. The first four parameters are strings, the field name spring messaging key, the drill page header spring messaging key, a database stored procedure name for the counts, and database stored procedure name for drill page values. The last parameter is an array list of strings which are spring messaging keys for the column headers on the drill page.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The way I built the new POJO does break the v-c-s-d model that is being used for the project, but I did not want to create additional project files to interact with an object that is only being used to display in that one table, and to drill into results from that table. If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful. But in this case, the POJO is largely self-contained as it has a tightly coupled DOA for its own database calls.
java spring spring-mvc pojo
java spring spring-mvc pojo
edited Jan 2 at 19:18
Nikolas
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
edited Jan 2 at 19:18
Nikolas
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
edited Jan 2 at 19:18
Nikolas
13.5k53669
edited Jan 2 at 19:18
Nikolas
13.5k53669
edited Jan 2 at 19:18
Nikolas
13.5k53669
13.5k53669
asked Jan 2 at 15:31
FeringFering
16512
asked Jan 2 at 15:31
FeringFering
16512
asked Jan 2 at 15:31
FeringFering
16512
16512
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The question is a little bit broad to answer with a single statement, so I cover all the key parts only. The first I answer the title question itself:
Should a POJO be connected to a view or controller?
The POJO is never connected to a view or a controller. It's an independent data structure, a bag of data to any library, framework or components (such as view or controller is). The idea is that this model shall be shared among views and controllers. More about POJO at Spring: Understanding POJO.
So my new object accepts 5 parameters.
Decompose objects to the smaller one and use the decorator to add them a functionality or state.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The 1-1 abstraction of a file and object is fine. Construct the object as immutable and let the data source origin to be the file only. Perform the add, update and delete actions through the methods which touch the data source origin - the file. Yet the object remains immutable which is the key for the maintainability. The List<MyObject> would represent the table well.
If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful.
For this reason, the service layer has been introduced.
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54009025%2fshould-a-pojo-be-connected-to-a-view-or-controller%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The question is a little bit broad to answer with a single statement, so I cover all the key parts only. The first I answer the title question itself:
Should a POJO be connected to a view or controller?
The POJO is never connected to a view or a controller. It's an independent data structure, a bag of data to any library, framework or components (such as view or controller is). The idea is that this model shall be shared among views and controllers. More about POJO at Spring: Understanding POJO.
So my new object accepts 5 parameters.
Decompose objects to the smaller one and use the decorator to add them a functionality or state.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The 1-1 abstraction of a file and object is fine. Construct the object as immutable and let the data source origin to be the file only. Perform the add, update and delete actions through the methods which touch the data source origin - the file. Yet the object remains immutable which is the key for the maintainability. The List<MyObject> would represent the table well.
If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful.
For this reason, the service layer has been introduced.
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
add a comment |
The question is a little bit broad to answer with a single statement, so I cover all the key parts only. The first I answer the title question itself:
Should a POJO be connected to a view or controller?
The POJO is never connected to a view or a controller. It's an independent data structure, a bag of data to any library, framework or components (such as view or controller is). The idea is that this model shall be shared among views and controllers. More about POJO at Spring: Understanding POJO.
So my new object accepts 5 parameters.
Decompose objects to the smaller one and use the decorator to add them a functionality or state.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The 1-1 abstraction of a file and object is fine. Construct the object as immutable and let the data source origin to be the file only. Perform the add, update and delete actions through the methods which touch the data source origin - the file. Yet the object remains immutable which is the key for the maintainability. The List<MyObject> would represent the table well.
If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful.
For this reason, the service layer has been introduced.
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
add a comment |
The question is a little bit broad to answer with a single statement, so I cover all the key parts only. The first I answer the title question itself:
Should a POJO be connected to a view or controller?
The POJO is never connected to a view or a controller. It's an independent data structure, a bag of data to any library, framework or components (such as view or controller is). The idea is that this model shall be shared among views and controllers. More about POJO at Spring: Understanding POJO.
So my new object accepts 5 parameters.
Decompose objects to the smaller one and use the decorator to add them a functionality or state.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The 1-1 abstraction of a file and object is fine. Construct the object as immutable and let the data source origin to be the file only. Perform the add, update and delete actions through the methods which touch the data source origin - the file. Yet the object remains immutable which is the key for the maintainability. The List<MyObject> would represent the table well.
If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful.
For this reason, the service layer has been introduced.
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
The question is a little bit broad to answer with a single statement, so I cover all the key parts only. The first I answer the title question itself:
Should a POJO be connected to a view or controller?
The POJO is never connected to a view or a controller. It's an independent data structure, a bag of data to any library, framework or components (such as view or controller is). The idea is that this model shall be shared among views and controllers. More about POJO at Spring: Understanding POJO.
So my new object accepts 5 parameters.
Decompose objects to the smaller one and use the decorator to add them a functionality or state.
Using the object I should be able to touch only the one file when I want to add or remove values from this table, without having to modify multiple pages. What I have not figured out is what the correct place to use it is. Would having the view call/create the object and for each element create a table listing for it or having the controller call/create the object and append the data to the view object be more appropriate?
The 1-1 abstraction of a file and object is fine. Construct the object as immutable and let the data source origin to be the file only. Perform the add, update and delete actions through the methods which touch the data source origin - the file. Yet the object remains immutable which is the key for the maintainability. The List<MyObject> would represent the table well.
If I was going to have more interactions with the object, then a service layer offering a rich listing of interactions might have been useful.
For this reason, the service layer has been introduced.
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
answered Jan 2 at 15:46
NikolasNikolas
13.5k53669
13.5k53669
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
add a comment |
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
The methods for new, modify, and delete are only returning results, they do not perform changes. Just reporting on the results of the scheduled job overnight so that humans can check the changes that occurred overnight if they wish.
– Fering
Jan 2 at 17:28
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
I find your use of immutable combined with maintainability confusing in the 1-1 abstraction section. Immutable means that it does not change (which makes me hate working with Java strings coming from a c++ background). I do not see how having the class immutable helps to give me stability or maintainability in the long run (I am talking about years and across server resets and migrations). I am not changing the object at any point as once its created all values come from the database calls. Yes declaring it final and immutable would serve to illustrate the point.
– Fering
Jan 2 at 17:53
1
1
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
To defend immutability, skim over the first 3 links at How immutability helps. I see you misunderstood the concept of immutability. It doesn't make an object a constant.
– Nikolas
Jan 2 at 18:13
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
When reading and learning about immutability this kind of design was never discussed or mentioned. The first link by Yegor is a wonderful example of immutable functionality and design. So yes, you were absolutely correct when you claimed I did not understand immutability.
– Fering
Jan 2 at 19:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54009025%2fshould-a-pojo-be-connected-to-a-view-or-controller%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
