Relationship between bean and view

Question

Relationship between bean and view

Navigation

#1 by (3 votes)
#2 by (1 votes)

3

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

My question is, is it worth (or, is it right) to create a specific% w / o for this leds table and use it to reference it in the three bean ? Taking into account that I will have a reduction of code and duplicity.

I believe that the way of implementation and what is done in these screens must be taken into account, but this specific led table always shows the same information from reading external data, it is not changed unless the whole process start again, with the collection of new data. I do not know if there is a relationship that says a views is only a view .

java java-bean spring jsf

asked by anonymous 28.06.2017 / 15:09

2 answers

1

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

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

There are very different opinions on the number of managed beans, the number of managed beans per page ... In my opinion, there are good practices, but a rule that applies to all situations I do not believe exists.

28.06.2017 / 15:44

Manage DataTable with lots of information What is the use of ASAX extensions?

score 3 · Accepted Answer

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

In a small program you may 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. In addition, in a serious project, you would still have to duplicate tests and various other elements relating to what is duplicated.

Of course, you have to have good judgment and do not try to abstract the code too much, but if the statement that the three screens actually show the same information is true, then avoiding duolicities is a good objective practice.

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 all three screens, so that changes in the table are something exclusive of the components related to it and the other screens and components do not need to be coupled to the operating mode of such a table.

Something that helps is thinking in terms of components. A good practice to create 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.