We Keep Coding

CustomerDAO alternative when Customer's fields are retrieved both from a third-party web-service and application's dedicated database

I have a Customer class. Its private field is a CustomerDAO interface which database-access methods are called by myCustomer.getAge() for example. CustomerDAO retrieves data from the application's dedicated database.
The problem is that a few fields of Customer now have to be retrieved from a third-party web-service. Logically calling some web-service doesn't belong to CustomerDAO (which is intended for communicating with a single database, right?).
What is the industry recommended approach in such cases?
Shall I just add another field CustomerWebServiceDAO (as interface) to Customer? And my Customer would use internally two different instances (CustomerDAO and CustomerWebServiceDAO). So DAO gets split into 2 separate classes... What if next I need access to another Web-service plus an additional database? What better solution/pattern can be used?
Adding web-service methods to initial CustomerDAO interface would mix database access with web-service access, which I think is not good.

If I understand your question right
you need to have a database service which has all GRUD operation of Customer and assume it will be called CustomerDBDao and another service Called CustomerAPIDao which is responsible of all web service operations and all services is called in a general service called CustomerDAO
which is filling data from both services and generate One Unified POJO this concept is called adapter design patter
https://www.tutorialspoint.com/design_pattern/adapter_pattern.htm

Convert Entity class to a lot of DTOs

I have a project where I need to store Users on database. I'm using Hibernate and in some part of module also Spring Data JPA experimentally.
I have a REST endpoint for register customer and I'm receiving there UserDTO object. After that in other service I need to convert it to UserEntity and save in database.
Now I created user settings page where I need to display some information about logged user. I don't want to sent UserDTO object because there is to much data so I need to create one more DTO class and Converter class. I feel it's a little bit tricky because every time when I wan to store or receive some specific data, I need to create new DTO and converter class so I have a lot of DTOs and Converters in my project. When I will need to change something on my Entity class, probably I will need also change a lot of converters.
Is this correct way or do you have any better solution for that?

You can use projection queries to create your DTO-s without converters.
Here is a short example with explanation: JPA - Basic Projections

MVC pattern, no database, where to store objects?

I'm working on a school project and or task is to design a project management tool. We are allowed to use any design pattern as long as we can explain how it's good according to the GRASP principles.
I'll give a synopsis of the project tool:
CRUD-functionality for projects
CRUD-functionality for tasks (a project has tasks)
CRUD-functionality for users (a user is assigned to tasks)
A simple GUI
We decided to go with the MVC-pattern and we are not allowed to use a database. My question is: Where should I store objects?
Should I do this in the controller? Currently we do it like this:
public class ProjectController
{
private ArrayList<Project> projects;
public ProjectController(TaskController taskController)
{
projects = new ArrayList<Project>();
}
}
I have a feeling there is something wrong with keeping the objects in the controller but I can't explain why. Anyone that can explain what's the best practice according to the GRASP-principles?
EDIT:
Thank you, learned from everyone something but can only pick one answer.

For a very short answer : NO, don't put your store in the controller. This is a bad idea and it goes against the MVC principle.
Usually, the model is the only place responsible for your data BUT it is frequent that the M part is split into :
Fetching the data.
Storing the data in the application.
The interesting part in this is that, no one cares where your data come from. A database, a file, an API rest. whatever, it doesn't matter.
I'm not saying i have the best solution for you but here is how you could do this with an example.
You store your user data into a file.
You create a php class UserDataRepository that fetches the user data files, and sets the data into your UserModel class.
From the controller, you call your UserDataReposiroty and get back your UserModel.
This way your controller doesn't have any idea how you are fetching the data. He just asks a repository to fetch them and it returns the UserModel that the controller is allowed to manipulate.
I hope this will help you

Increase abstraction.. Create a model class. Create your arraylist (model objects) there. Your controller should still access/call model methods.
Tomorrow, you might want to dump that data into a file or into a DB, you will have one hell of a ride doing that with the current design. So separate your model from your controller and keep the design clean.

No. If you store data in the controller then you are not using MVC. You have to do it in the Model. You can store in memory or files, but always store data throw the model. For example, you could implement DAO pattern to manipulate data.
Maybe, not now, but then you will need a database. With DAO pattern, it won't be difficult to adapt your current persistence kind to a database.

In MVC pattern, M means models, V means view, C means controller. A common MVC application progress is that once a request is coming, controller get it and do necessary processing, retrieving results data, then pass the results data to view for rendering. After view layer is rendered, it displays to users via GUI.
So controller can be regarded as a commander, it controls process, but it is not good to handle data retrieving in controller. Model should be responsible for retrieving and organizing data. That means data objects should be stored in Model instead of Controller, Controller calls Model to retrieve data objects. Take Java application as example, usually these parts are needed:
ProjectController, it calls ProjectService.getAllProjects() method to retrieve result. Once retrieved, view layer use the result to render GUI for display. I suggest Controller layer should be thin.
ProjectService, it has method getAllProjects(), this method calls ProjectDAO.getAllProjects() method to retrieve projects data, and maybe other handling. Here business logic goes.
ProjectDAO, it has several methods which deal with Project objects, deal with data in this layer! But these methods should be independent with business logic(as business logic should be deal in ProjectService).
Project object.
Hope it helps.

Specific configurations for different items using same table

So we have an ITEM, TV, LCD and PROJECTOR.
We have DAO and Service object for TV, LCD and PROJECTOR that also are ITEM objects. Meaning that those tables all extends the ITEM table.
You can access these items through an UI and an API service.
Right now, I am in the need to put specific UI configurations that are not related at all with the API. Lets say that I need in the UI a configuration for each item to display or not display an image of the item on it, lets call it showImageFlag. This value can be modified from the Item's UI, this is a checkbox.
I've been thinking about a few options here:
Add a column SHOW_IMAGE_FLAG to the ITEM table and it's DAO and service object. On the service object put a #JSonIgnore flag so it is ignored on the API side, but we can use it normally in the UI. ------- My concern with this approach is that in the future we might need more configuration for these items or maybe others than tv, lcd and projector. So this will always will push us to add a new column to the table. Another concern is that we might be migrating all form post ui to use the REST API, so we are going to have to do something about that JsonIgnored property.
A ITEM_CONFIG (id, item_id, configuration, value) table FKed to the ITEM.id with a key/value approach to save N configuration related to specific items. So on every web controller I will be passing a ItemConfig object with all configurations related to the requested ITEM. -------- My concern with this one, is how should I map this to the form (using spring mvc) and how should I persist when the configuration changes on the UI.
Please free to comment and suggest any new option for this.

Second point is more feasible.
Also,you can have another service layer which will be responsible for saving mapping part and below service layer there will be UI controller layer which will actually map the changes to its undergoing presentation i.e. UI layer.

I would think about adding Item(id)--ItemUI(item_id) as 1:1.
Then you can add all your UI specific about an item to the ItemUI attributes.
Also you could request UI configuration with a second call to another service.

From the two options I'll go for number one. The only problem that comes up is when the UI is migrated to use the API. In that case you won't be using #JsonIgnore, instead you will be using Json Views.
You can create classes representing specific views on your data and use them to tag your attributes with #JsonView(MyView.class). Finally, you can serialize your beans using objectMapper.writeValueUsingView(out, beanInstance, MyView.class);
In your case you could create an view class MyAPIView and annotate all fields but SHOW_IMAGE_FLAG with #JsonView(MyAPIView.class) (Note MyAPIView is an empty class used for tagging purposes, with no logic nor attributes).
If you call objectMapper.writeValueUsingView(out, beanInstance, MyAPIView.class); you wont serialize the SHOW_IMAGE_FLAG attribute. If you call objectMapper.writeValue(out, beanInstance) you will serialize the attribute.
You must determine at runtime the view to be used. If you are using OAuth you could select view depending on the connected client.
Eventually, you can create several views and apply inheritance. Take a look at jacksons doc.

I ended up with a config table for items called ITEM_CONFIG (ITEM_ID, UI_PROPERTIES)
On the UI_Properties I save a JSON string, which is mapped to a String propertie on the DAO model, but as a HashMap<String, Object> on the service model.
I have a converter that maps the value from the dao model to the hasmap on the service object, "automatically".
On the controller (in the BaseController, parent of every WebController [not rest]), I added a method to get the config from the ItemConfigService and then set the value on the response (Model in SpringMVC) using the hasmap key as the parameter and the value as the parameter value.
This is working very clean and we haven't had any issues since last week.

How to display the same data on all pages in Spring Framework 3.0?

I have some text data from database that I want to display it on all pages on my site. (for example news block etc.) How can I load and pass it to View in Spring Framework 3.0?
I don't want to create some method, which will retrieve data, and call it from each controller...

Use a HandlerInterceptor, which is built for this purpose - you can specify a piece of logic to execute before or after the execution of your controllers (or a list of controllers - it is up to you to map an interceptor to the controllers it should apply to) by implementing a preHandle() and/or postHandle() method. The latter receives the ModelAndView as an input, allowing you to add model attributes to it.
This way the logic to add some data to the model exists in just one place, can be selectively configured to apply to all or some pages, etc.