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:
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 have a question about the MVC pattern.
I am creating a maze game in JAVA with swing and I'm trying to use the MVC pattern with it. So far it goes well but I don't get the "rules" of MVC.
Let's say I have two models: one for creating a maze and the other one for the player.
The player get's it's location from the maze created in the maze model. You see, the player determines it's location from that maze and decides if it can move to a new location.
This part I understand, But can my player model ask the maze model for the maze? or is it out of the question in MVC used in a java swing application? (interactions between models).
thanks!
öhm, this is one aspect of MVC that many people discuss all the time. For ME it just means that you have the really stupid VIEW-Part which does nothing else than showing Data and taking request. This Requests are forwarded to the Controller, which does some stuff with them and then call the MODEL to do the real work. So from my point of View, you are totally fine when Models talk to each other. But to rreduce dependency and improve encapsulation, i let my models get the other needed Models over the appropriate Controller, so i can use dependency Injection.
I see the COntrollers in my MVC apps as some kind of switchboard, which "regulate the traffic" and provide a place where you can call from inside the building to get a line to some co-worker, and from the outside you have to talk to the secretary.
I know other will say this is WRONG/RIGHT, but for me it works, even in teams.
MVC. Models only model your data and access that data. Views only serve the data to the user. The controller is like a conductor, putting it all together. Whether a model can be made up of another model, which I think you are asking, yes, but it might not be the best in terms of how tightly coupled your objects are. Is a player made of a maze object or just a location? Your question appears to be more about OOP principles than one of MVC. Unless of course I am miss reading your question.
I am trying to introduce some good practices into my website coding, so I started to look into MVC, since it is a buzzword in website designing :-) I am confused by the MVC pattern though. I am used to thinking in a Three-tier pattern, where you have 3 layers:
presentation
logic
data
Two things confuse me around MVC:
"Model" component is often presented as the data layer above (database abstraction). But where does the "high-level" logic belong to? Like deciding what you will do with the data and how, checking permissions etc. Sometimes I've seen some of this in the controller, but it is really confusing for me to decide which belongs where.
The MVC pattern is presented as a circle of 3 components which send messages to each other, like M -> V, V -> C, C -> M, and the other way around. I understand perfectly the Three-tier design, where one layer calls the layer below itself, but not the other way around! The functions in your programming language can call other functions (you can call it "sending a message") - but it is an oriented tree graph. But how can the lower layer, or, how can the called function "send a message" or "notify" the calling function?
Maybe I am too much concerned by the MVC pattern and could happily stay with my Three-tier designing? Anyway, I would like to understand MVC pattern to at least see if it is worth using for me.
The model is another way of saying your domain knowledge, your controller should be deciding what models to display, update, create, and your view should just present the data the controller has decided to present. To address your second question the model is normally passed to the view through the controller to the view for the data to be presented.
For more details scroll down the the Model View Controller section of this page
Before start work on implementation Model layout, I ask few question on this site:
Correct design for entity classes. Need recommendations
Java Generics. What benefit in my case?
and
Two classes with almost duplicate code inside
Users give me many good and perfect recommendations.
In result, I create next implementation for my Model Layout:
Can you please look on my screenshot. And tell me,
I correct understang all?
And my implementation success?
P.S. link on lange image: http://www.dropmocks.com/mBf62w
Your solution lacks of one more thing, which is Service Layer. This is important, since you will use DAOs within the service layer to perform some business logic. Usually Database Transactions are also defined on the service layer, so keep that in mind.
I would also get rid of Persistent interface, since I don't see how it helps in anything, and instead - I would use abstract class for PersistentImpl. AbstractEntity would be more appropriate name then.
Other than that - your solution is neat and clean - I'm using it across several project of mine and I'm very happy with it :)
I don't bother with a dao when I use hibernate, seems unnecessary/superfluous and just have entities and a service layer (and a controller and view).
There are however differing views on this.
Say, You have an application which lists down users in your application. Ideally, if you were writing code to achieve this in Java, irrespective of what your UI layer is, I would think that you would write code which retrieves result set from the database and maps it to your application object. So, in this scenario, you are looking at your ORM / Data layer doing its thing and creating a list of "User" objects.
Let's assume that your User object looks as follows:
public class User {
private String userName;
private int userid;
}
You can now use this list of "User" objects, in any UI. (Swing / Webapp).
Now, imagine a scenario, where you have to list down the userName and a count of say, departments or whatever and this is a very specific screen in a webapp. So you are looking a object structure like this:
public class UserViewBean {
private String userName;
private int countDepartments;
}
The easiest way of doing this is writing SQL for retrieving department count along with user name in one query. If I you to write such a query, where would you have this query? In your jsp? But, if you were doing this in a MVC framework, would you move this query to your data layer, get the result set, convert it to UserViewBean and send it to your jsp in request scope? If you write queries directly into jsps/if you are making use of connections directly in JSP, isn't that a bad practice?
I know, some of you might say, 'hey, you got your object composition wrong! if department is linked to user, you would want to create a list of departments in your User object' - Yes, I agree. But, think of this scenario - Say, I don't need this department count information anywhere else in my application other than this one screen. Are you saying that whereever I load my User object from the database, I would have to load a list of dependency objects, even if I won't be using them? How long will your object graph get with all the relational integrity? Yes, I do know that you have ORMs for this very reason, so that you get benefits of lazy loading and stuff, but I dont have the privilage to use one.
The bottom line question here is:
Would you write sqls in to your JSP if it serves just one screen? OR
Would you compose an anemic object
that caters to your view and make
your business layer return this
object for this screen - just to make
it look a bit OOish? OR
irrespective of what your screen
demands, would you compose your
objects such that an object graph
is loaded and you would get the
size of that list?
What is the best practice here?
I would never put SQL in a JSP. I would use Spring MVC or Struts controllers, or servlets to contain all of that type of logic. It allows for better error handling among other things (you can forward to error pages when queries fail).
If you really must do this, use the JSTL SQL tags.
Personally, I take a simple pragmatic approach. If I was writing screen that just displays a list of users with their deparment count, so that the entire code is maybe a page, and I don't expect this code to be used on any other screen, I'd probably just throw it all in the JSP. Yes, I know there are all the MVC purists who will say, "business logic should never go in a JSP". But aside from a dogmatic rule, why not? What would it hurt in a case like this?
If I found that I had two screens, maybe one where I had to simply display the list and another where I had to do some additional processing on the list, then I would certainly pull the common code out into a class that was called from both places.
I believe that the criteria should be: What produces the most maintainable code? What is shortest and easiest to understand? What produces the least linkages between modules? etc.
I adamantly refuse to accept the principle: "In some cases this approach leads to problems, therefore never use it." If sometimes it leads to problems, then don't use it in the cases where it leads to problems. Or worse, "Somebody wrote it in a book, therefore it cannot be questioned." Sure, there are some rules that are valid 99.99% of the time, so it gets to be pointless to check if this particular case is an exception. But there are lots of rules that are good 51% of the time and people leap from "mostly" to "always".
Would you write sqls in to your JSP if it serves just one screen?
In a prototype, just as a quick hack - maybe. In any other situation, not to mention a production environment - NEVER.
Use a proper MVC framework to separate business logic from presentation.
I am not even sure that JSP should be used, but for trivial applications. If you really have to use them, use MVC pattern or encapsulate your logic in a JavaBean.
Have a look at JPA which allow you to do object manipulations which then is persisted in the database
I wouldn't put SQL in a jsp for fear of forgetting it in future maintenance. Think of the poor guy maintaining your code-- poor guy = you in 10 months or whenever the database is restructured-- and at least put all SQL in the same general region.