I'm adding some code to my project that allows drag and drop.
The Form used for the actual dropping is obviously part of the view/presentation layer. However, there's a question mark on a TransferHandler class that contains the actual logic which detects and validates objects dropped on the window.
Considering I have presentation, logic and data layers, where could this class be placed in the structure?
If it is totally related to presentation layer, then at presentation layer.
or if the same thing is needed when your presentation changes than at logic (service) layer.
I would suggest a presentation layer, but creating some package for example util, which will contain all classes you use to help your view features like drag-adnd-drop.
Which class is the information expert, meaning the class with the most information pertaining to the operation? It seems like the presentation layer contains the class that is the information expert, thus it would be reasonable to place the code there. Should this action affect domain objects though you may want to look at implementing a use case controller which would be called from the presentation layer.
Related
I built a web application using spring-boot, spring-mvc and hibernate. I used the DAO in UI directly by just wrapping them in another objects. It makes my DAL and Presentation layer quite tightly coupled.
As per my understanding, mvc architecture reduces coupling by separating out each component and i worked against that. :(
Is it okay to do what i did? As it saves presentation layer object conversion to DAO to persist them in DB.
What is recommended and best way to design? what will the pay-off with current design (quite tightly coupled)?
I'm not able to figure out, could anyone please help me to understand it.
Thanks in advance!!
I used to do it like that:
I create several layers: the UI layer, the BLL layer and the DAL layer. Then I create the models for each of them. For example: MyUser_UI.java, MyUser_Bll.java and MyUser_Dal.java. This models are so-called POJO, they are used to carry data between layers. As you can see, MyUser_xxx.java(s) have similar property, so I use a automatic object mapper named DozerBeanMapper to help me to transmit data from one to another. That's what I have done.
I promise that is a practical method, however, obviously, it is far from the best. Too many classes I must maintain. Think about that: one day I want to add a new property for MyUser_xxx.java, I must change three places. I often miss something and get errors. So I changed to another way.
I extract the POJO to a separate package. All the three layers can access this package. In doing so, I feel better. But it also brings some other problems. POJOs requirement for each layer is often a bit different. So I have to create the base class MyUser.java, and the MyUserEx.java derived from the base.
It is a bit disappointing that I don't think there is a best design. But we can combine many methods to make our code better. Witch do you prefer? It's up to you.
Martin Fowler has a fairly seminal article on layering from his P of EAA book:
http://martinfowler.com/eaaCatalog/serviceLayer.html
I was taught UML early on in university but all the examples were always with simple console applications. Now that I have been assigned to develop a project with a graphical interface (using Java) and was required to submit a UML model, I haven't got a clue how to go about representing the graphical frontend aspect of the application in tandem with the non graphical backend classes. I'm not quite sure where to even start.
How would you suggest I go about doing this?
Usually UI modeling involves 3 things:
How the UI looks like: this is not usually done in UML. You need a tool like Visio or Pencil to do that.
How the UI is structured: This considers how the UI is structured into classes. How these classes are related to each other (dependencies, navigation, ...). How they are related to domain classes. How they are related to the Use Cases (which ones they implement). This fits naturally in UML structural diagrams: class diagram, package diagram, component diagram, ...
How the UI behaves in runtime: How certain actions cause objects to be created and methods to be called to perform the desired actions. This fits naturally in UML behavioral diagrams : sequence diagram, communication/collaboration diagram, activity diagram.
So basically in your UML model, UI classes (Screens, Applets, Pages, ...) will appear like normal classes. This will allow UI structure and behavior to fit in your application view models.
Note that there are tools that make use of UML profiles to provide UI mocking as alternative to graphical tools like Visio. In this custom profile you may find for example stereotyped class called << screen >> and stereotyped dependency called << navigation >> to model how UI elements trigger UI navigation to other screens.
I think you need to start by asking what you want to model and then that leads to you work out whether UML is useful and if so, which parts. Start by asking who is going to use this model and for what. Model with a purpose.
If you want to model the class structure of your application, then a UML class model might be useful. But even then, are you trying to illustrate the UI classes or the information (domain) structure, or both?
If you are trying to show how the runtime interactions work, then a sequence diagram might be useful.
If it is modularisation of code and dependencies between modules, a package diagram would do this.
If you have a complex user interface program with a sophisticated component structure which you want to explain, then it's no different to server software and a component diagram would be useful.
Whenever creating a model ask why you are doing it, for whom and what they want from it. That leads you to select something useful rather than just doing "busy work".
Asides from the previous answers, a common design for UI is one of model-view-controller (MVC). Some UML tools actually have stereotypes to help you with representing these elements. The model is the data that you want to show, the view is how it is displayed, and the controller links the two, taking the input to the UI and processing it to change the display with the new data from the model.
It is also easy and useful to create sequence diagrams for a MVC system to show the actions and their effects.
I am trying to confirm whether this statement is true:
Model includes both:
persistence layer: essentially DAOs + classes representing tables + DTOs
service layer: Combinations of DAOS + some logic
Could you also please reference/support your answer? I believed I've seen in Spring Framework good diagram, but no matter how searched this time I can't find it.
And the other point: I was always wondering why we abstract stuff so heavily that at some point people just stop understanding, is it done to increase our own value? :\
For example analysing Spring MVC I can say that central piece is controller no matter how you name other layers it is Controller who decides where to go what to extract , how to validate it and which view/controller to pass it on. Yet this simple statement is never found in formal articles keep confusing people.
So Controller is our god. Controller asking for some method within a class that call methods of another class. On top of it all is wired with dependency injection as we only need a single instance for objects of singleton nature. Controller>Service>DAO that's it .I would really appreciate book written by pragmatics.
If people would write books based on how things really are and not how to make look them beautifully drawn in diagrams or written the endless questions as such would never raise in a first place. And I thank stackoverflow for people that always show me the path. ;-)
MVC and the DAO/Service architecture are less concepts which are contained within each other than which sit next to each other.
In MVC, your controller takes care of fetching all the data, placing it in a model in some way, and passing the model to the view to be rendered. If you are also using DAO/Service architecture, your DAOs/Services might return an entity which contains all the information you will be displaying on a given page, and people often use these as the model for the view if things are relatively simple.
The problem with this tactic is you end up having dependencies between your views and the specific implementation of your model. Also, if you later decide you need some extra information which is not included in your model, you'll have to rewrite your view to account for this. This is why it is often suggested you do as much preparation of your data in your controller before passing a very simple model (a Map) to the view.
Here's a diagram showing the separation of layers:
When utilizing a UI abstraction, then the data you're displaying is protected from implementation changes in the UI layer. Does/should/can this extend to higher-level things, like for example, display as a tree or a grid? I can't work out how to insulate the abstraction from the higher-level details of how the UI is going to display the data garnered through said abstraction.
You want to start with the Model-View-Controller architecture. This allows you to insulate, as much as possible, your user interface from data changes. The Model layer is your data objects. The View layer is your actual Swing components. The Controller layer is your listeners. The Model layer is written independently of the other two, with no knowledge of the classes. The View layer is written with no knowledge of the Controller layer.
If you require more abstraction than that, you can create interfaces for your Model layer so that several different data models can all use the same interface. This way, it doesn't matter what data you give to the View layer, it just displays it through the use of the interface.
Also realize that it's not always possible to do what you're asking. Sometimes a user interface needs to be written specifically for the data being displayed. A tree isn't always a tree, and a grid isn't always a grid. It works well to customize the View layer to match the data being displayed. This way, you can tailor the functionality specifically to the data being manipulated and create a better interface for your users.
Certainly, though, it should be done where it makes sense. This is where experience and judgment play a big factor.
I have a bunch of model objects.
These objects end up being rendered as views (say forms) in a rich client app.
I started to annotate the fields in the model objects (Java annotations) with things that let me render them as forms on the fly (e.g displayname, group, page, validvalues).
I now realise that the view has crept into the model.
How should I seperate the view logic out of the model objects?
TECH: Java, Java Annotations, Eclipse RCP
EDIT:My question is theoretic, but I would also like some concrete (implementation) advice.
At the risk of stating the obvious, what you need to do is store the display-related information somewhere else. Don't put the page in the model code - create an object for the interface, have it contain page objects, and make each page know what values it displays. This may require a certain amount of refactoring.
Having said that, not everything you mention is 'view'. Valid values for a field is part of the logic of the field; it should be considered part of the model, not the view. Likewise if 'group' is a logical grouping, rather than about placement in the interface, it might be considered part of the model.
You could replace the annotations:
#DisplayName("My Fancy Name")
#DisplayGroup("My Fancy Group")
public String myProperty;
by a separate descriptor class:
Descriptor desc = new Descriptor(MyClass.class, "myProperty");
desc.setDisplayName("My Fancy Name");
desc.setDisplayGroup("My Fancy Group");
You have clean separation of concerns, but you loose compile time safety (in Java, because Java does not have property references).
You could look at the MVC pattern and introduce a controller into the mix to provide the communication between the model and the view.
This prevents the view creeping into the model as the view never talks to the model it only talks to the controller which is responsible for all interaction between the model and the view
If I get you right - you use the model classes as a (static) model to create (part of) the view? Why not - in your case, the model classes (with annotations) are one model, the objects another one.
As long as the annotations just give hints (like #Textfield) I don't see a problem. If the model already contains references to view objects (like a reference to a Textfield), then there's need for refactoring. Easiest would be to move the model classes in a separate plugin and do not add any *.ui type and view plugins as dependencies. Then fix the errors ;)
... and have a look at jface databinding! Very useful in a MVC/MVP architecture!
The view should have a reference to the model, but the model should not have a reference to the view.
The view can write to the model.
The view listens for events on the model, such as a property change, or collection change.
The view then updates itself when the model changes.
You should definitely not have methods on a model that render the model as a view.