Relation between bean and view

Question

I have three views that show the same table with a sequence of leds and information, I have a class service that makes the business logic to know which led and which color to show, in my bean responsible for the view I receive this method with the information ready and step to the components of the view that show the led.

My question is, is it worth (or, is it correct) creating a bean specific to this table of leds and use it to reference it in the three views? Taking into account that I will have a code reduction and duplicity.

I believe that the form of implementation and what is done on these screens should be taken into account, but this specific led table always shows the same information resulting from reading external data, it is not changed unless the whole process starts again, with the collection of new data. I don’t know if there’s a relationship that says view is for only one bean.

Answer 1

Removing duplicity is important, especially in the design or development phase, because after the program is launched the cost can be very high and makes maintenance rather difficult.

In a small program you can argue that this is a matter of opinion, but if you have worked on any project with reasonable complexity you should know that in the end the product will end up with inconsistencies when someone changes one or another duplicate part. Also, in a serious project, you would still have to duplicate tests and several other elements relating to what is duplicated.

Of course it is necessary to have common sense and not try to abstract too much the code, but if it is true the statement that the three screens really show the same information, then avoid duolicities is a good practice very objective.

In addition to doing this on the Java side, do the same in the view, that is, create a single component that can be included in the three screens, in such a way that changes in the table are something exclusive of the components related to it and the other screens and components need not be coupled to the mode of operation of such table.

Something that helps is thinking in terms of components. A good practice for creating reusable components in general is to always use them as a black box, as if you were importing a third-party component. This consists of applying well encapsulation, hiding the inner workings to the maximum, and exposing only the necessary integration or extension points.

Answer 2

I recommend this article manged Beans, do not complicate, simplify, but I’ll also give my opinion.

If you guarantee that it will always be the same on all pages, and that nothing on any of the pages can interfere with this table, it is a good option to avoid copying and pasting code.

There are very different opinions about the amount of Managed Beans, the amount of Managed Beans per page... In my opinion, there are good practices, but a rule that applies to all situations I do not believe there is.