Currently doing a group project for college in Java. The assignment is to produce a zero-conf based distributed system. Our group decided on a conference chat application, using client-server architecture. As I joined the group late, a bulk of the code was already completed, and they had decided to develop an MVC architecture for the project. I have experience myself with MVC through Rails development, and can appreciate how handy it is in that context. However, I can't see the benefits of using it the way it has been implemented by my group.
There are two classes for Client and Server, each of which contains methods for sending and receiving datagrams, and fields such as sockets to enable the sending. There are also ServerController and ClientController classes. Each of these classes consists of only one field(a Server and a Client respectively), and all the methods are either wrappers for the public methods of the Server or Client, or simple utility methods. An example would be:
public void closeDownServer(){
server.closeDownServer();
}
To me, this seems completely pointless, and that in this instance MVC has been implemented just for the sake of using a design pattern. Can anyone tell me if there is any benefit to coding the application in this way? Is there any need for these controller classes at all?
The purpose of MVC is to provide abstraction to make later changes easier to implement, and to decouple your components. That might be why you see it as pointless now.... because your application is small and simple. If it will stay that way, then MVC might just be added bloat to your application. But if it's going to grow, MVC might be helpful for future development.
Consider a few cases that might illustrate why you would want to use MVC or an implementation that let model and view access each other directly, without a controller.
What if you need to perform some other actions when "closing the
server" that aren't related to your server class specifically? Where
would you do this?
What if you wanted to change your server implementation to a third party package? Would you rather change your controller code or change
implementation specific code in all your views?
What if you change the database you are using to store application data? Do you want your UI developers worrying about changing code in
the front end to accommodate this?
All of the above situations can be mitigated by using MVC, which will give you the proper separation of concerns and abstraction necessary to make developing and improving/changing code easier.
with a description this deep it is impossible to say if MVC pattern really is valid to your design or not.
But I can say this: there is a pattern far more important pattern than MVC pattern - the pattern of SIMPLICITY: if something in your code is completely useless and doing nothing, GET RID OF IT! There is no point having some class just because of some authority once said so.
Quite often when implementing MVC model, I have seen the controller combined with the view, especially when the app is simple. So you are not alone making this question. Later, if the requirement arises (multiple different views for instance) you can separate the controllers.
The controller means that you can change the behaviour of the view binding to the model (i.e., user input is transformed into the model by the controller). In this context, I'd say that a controller generally isn't needed, since you won't need to change this behaviour in the future.
When developing games and I need to implement MVC, I normally leave out the controller too (it's combined with the view).
Related
We are currently planing our project and decided to use Vaadin. Right now we are a bit stuck figuring out how we could organize our code quite well without spending to much time. It seems MVP is a good practice for vaadin, but we are all new to the framework and it seems that quite a few people are really struggling with it. During our research we noticed that there are only very abstract tutorials and outdated frameworks. In the vaadin book also a layered architecture is recommended which we wanted to use. Our application isn't too complex (comparable to a usual businessbackend).
Is there maybe an elegant and simple solution to decouple the view,while also using the Designer?
We are also planning to use Spring Security and UI.
Thanks in advance
In my latest project I'm using Spring alongside with Vaadin and, although lots of boilerplate is added, your classes will be smaller, better organised, with single responsibility. In my case, I follow the architecture below:
Layout: class that contains the UI elements and it's design/layout.
Controller: handles all the events and user actions that a layout has. A controller only responsible of a single layout.
View: View class is the main "controller" for a specific URI fragment. If it gets too complex or with subviews, a controller class is created and injected.
Service: contains the business logic of the data. While the "Controller" handles the user interaction, the service is responsible of the business logic and data.
Repository: SpringData JPA repositories. Implement the CRUD operation and custom queries.
Model: Database entities.
Extra packages:
Event: I recommend using EventBus alongside the application.
Helpers: For that stuff that you don't know where it really fits in.
Configuration: Configuration and properties fetched from application.properties (if using SpringBoot).
Using this pattern you'll avoid ending up with spaghetti code and mixing up responsibilities on the same class. Regarding the Vaadin Designer, with this pattern it's completely independent as your layout can either be pure java or the pseudo-html.
I come from J2EE background and am trying to write an application with Play and angular js. The application is basically a booking app which basically looks like this:
https://gb.youcanbook.me/demos.jsp?template=generic&theme=city
Up until now all things were nice and easy but now there's a design decision that I need to make. In the Play framework, as I understand, the routing happens under Controller and the business logic goes under Model classes. Model classes essentially are EBean annotated domain classes. As per my limited understanding, this is where all the heavy lifting of the application/business logic needs to happen.
Coming from a J2EE background, my mind poses a question. Is this the right way to go? I know I can easily create another service class and just call them straight away from the Controller. But, is that the right way to go? Or has Play! just given us the freedom to go whichever route we want to take?
Also, in my case, I am using Firebase as my backend store so #EBean annotated classes don't make much sense. I can use spring but I don't want to take that route as that would mix in J2EE flavour which I want to avoid for the time being.
I have a general question about the correct (or maybe: the best) way to handle data from GUI to DAO.
I built a project where GUI input is being validated and sent directly to a DAO class which handles (via Hibernate) the database updates/inserts.
Now I decided to split DAO and GUI up into two separate projects and use a REST WS with Spring integration to handle the data. I considered this, because I thought this might be a good idea for future projects (advantage of course being the complete separation of the GUI from DAO).
For the moment I have a bit of a problem of making this all work (Spring error creating bean xStreamMarshaller). But before I try unnecessarily I wanted to know: Is that really a good approach?
Is this really a correct way or am I doing something completely unnecessary?
I think this post can be useful for you:
Spring MVC RESTful multiple view - 404 Not Found
I like the idea to work with restful, because you can really split the application not just in the back-end, but in the front-end as well. This way you can just get JSON in your javascript. But of course each case is different each other.
Follows a video about the subject: Designing a REST-ful API Using Spring 3
I am a S/W developer working on a Java web application.
I have very limited knowledge of Java and want to understand my application architecture from a very high level in simple terms. Being a developer, I do not completely understand the big picture.
Can anyone help me understand this?
Each layer represents a place where some problems are solved is similar way, often using some particular libraries or frameworks. In trying to understand this work your way down through the layers. BUT, note that each layer hides the details underneath, you don't need to understand the details of lower layers in order to understand one layer.
So the Struts piece is dealing with the User-Interface related issues of understanding user requests choosing some business logic to invoke and choosing how to display the results back to the user. It doesn't concern itself with how the business logic works, that's the job of the next layer down.
By Business Logic I mean the Java (or other language) code that expresses the realities of a the customer's business. For example in a retail application we might need to work out discounts for particular volumes of orders. So the UI layer wants to display the price for a customer's order. It doesn't have any discount logic itself, instead it says to the business logic layer "Customer X is order N widgets and M zettuls, when can we supply and how much shall we charge" and the business logic figures out the pricing for this customer, which might depend on all sorts of things such as the status of the customer, the number things we have in stock, the size of the order and so on. The UI just gets an answer £450, to be delivered 16th September, and displays it.
That leads to questions such as "why separate the business logic to its own layer?" There are several possible reasons:
The business logic might be used by some completely different UI as well
It pre-exists, from some older system
Our brains are too small to think about UI and Business Logic at the same time
We have different teams working on UI and BL - different skills are needed
This same way of thinking follows down the layers. Th important thing when thinking about each layer is to try to focus on the role of the layer and treat the other layers as black-boxes. Our brains tend to be too small to think about the whole thing at the same time. I can almost feel myself changing mode as I shift between the layers - take off my UI head, put on my persistence head.
There's plenty of material "out there" about each layer. Suggest you start by reading up about one of them and ask specific questions if you get stuck.
Looks like a standard "enterprisy" application to me.
Interface
This app. is primarily intended to be used via web browsers by humans. This interface or UI layer (in a broad sense) is build using the MVC framework Struts. If you don't know MVC, then it's a good idea to read up on this term.
The app. also exposes web service interface, which is intended to be used by non-humans (other applications or scripts).
So, 2 kinds of interface is provided.
Business logic
Request coming from the 2 interfaces noted above, ultimately talk to the lower half (App. tier) to get some real job done. The actual process (calculating stuff, storing stuff and what not) happens here. Note also that this tier also talks to external systems (via Service Gateway) in order to complete the requests.
The reason they separated the system like this can vary. If it's a very simple, small app. then it doesn't pay off to have these abstractions, so it's probably a quite complex system. Maybe the app. tier is some legacy app. and they wanted to put some better UI on top of it. Maybe the app. tier and the web tier happened to use different technology stack. Or perhaps the app. tier is used by many other external systems. It also makes updating each services/replacing each services etc. easier, so maybe they are anticipating that. Anyways, it looks like a very common SOA type of design.
Not sure what else you might want to know. I see that the designer intends to use distributed cache in both tiers. All in all, it's a very common type of system integration diagram.
App Tier - Where the basic application logic resides (think of a basic console-only program).
Database - MySQL, Oracle... server
DOs - Short for Domain Objects. If anemic usually limited to getters/setters and can be synonymous with Entities (#Entity).
Data Access Objects - Objects using DAO pattern to fetch domain objects from the database. Could be considered equivalent as DAL (Data Access Layer) although this might not fit here. Usually uses a persistence/mapping framework such as Hibernate or iBatis.
Domain Model - Where Domain (domain being what has been studied/analyzed from requirements) Classes are packaged and associated (one-to-one, many-to-one, ...). Sometimes there are even composited in other container classes.
Core Application Services - Groups Services classes which could be equated to the Business Logic Layer (BLL). Biz services handle the Domain Model, Application Services are relative to the Application (methods don't manipulated Domain) and not sure what System Services are supposed to do. I'm also not sure what the distinction between Core and the Application Service block is.
Facade/Interface - This is where all the communication is done with other Tiers. It helps to fully understand interfaces and the Facade pattern.
TOs: Transfer Objects. Related to Domain Objects and used for transferring as the name implies.
Web Tier - All the logic added to make the application accessible from the Web.
Business Delegate: Block using delegation pattern? Here it apparently plays the middle man between Application facade and the Presentation Tier using TOs.
Model: Notion relative to the MVC pattern and variants. With JSF I know that beans are usually linked to JSPs. This model is to be distinguished from the Domain Model. It is created for the purposes of presentation and might contain information that has nothing to do with the data being manipulated in the application tier and is specific to the web tier.
View: Notion relative to the MVC pattern and variants. JSPs represent individual pages and use their own markup.
Session: Look up theory on sessions (necessary as HTTP is stateless).
ApplicationContext: Groups instances/settings that can be pulled into from anywhere. Often associated in the Java world with the Spring framework. To not be confused with UglyGlobalVar/singletons.
Front controller: Could be considered as equivalent to Controller of MVC although the Front Controller pattern appears to be more specific. Servlets are considered as controllers as they handle communication (GET, POST...) and coordinate the model/view. Not familiar with Struts but imagine that the framework implements classes to represent user actions.
Presentation Tier: Simply all of the logic used for outside presentation.
Filters: Can be used to filter requests, for example to redirect a request to a login page.
Feel free to add/correct this description.
I need to implement quite big system in Seam. I'm considering the way of designing the architecture. If it's good to use page controllers or application controllers or front controller or every each of them. If it's helpful to use backend bean or maybe there's no need to do that. If you have any suggestion or link to helpful article I will appreciate it.
Thanks a lot!
Daniel Mikucki
If you need to learn a lot about Seam for a project, I recommend you get the Seam In Action book, which is the best on the subject.
To answer your question, personally I prefer to use the pull-MVC style in Seam, where you refer to data in your view templates that Seam takes care of initialising, as needed, using #Factory methods. However, there is more than one way to do it in Seam, so it is worth reading about the alternatives first, hence the book recommendation.
Alternatively, build a few Seam applications first to throw away before you try to build one 'right' :)
Daniel,
It is good practice to use a front controller, most people aren't aware of that design pattern.
It is a really good design pattern to use because it ensures you are accessing the application through a single entry point. You can monitor everything that comes and goes easily with less configuration. You reduce the amount of possible code duplication because there is a single entry point. In addition to having less code to maintain, the code should be easier to follow since there is only one way in. You can then easily follow the execution flow of the application.
Unfortunately for Seam, there isn't really a front controller pattern. I haven't spent as much time as I would like to develop my own, but security and audit-ability are my number one focus.
As far as page / application controllers go, in Seam, you have more contexts or scopes available. Event, Page, Conversation, Session, Application, to name most of them.
If you're developing a controller or in Seam, a page action, most of the time, it will be event based. That is the shortest lived scope. If you have page flows, you would then use conversational-scoped components.
Take a look at the examples in the source code. You can do a lot with very little code, it is amazing, but at the same time, there is a lot going on that may take a while to pick up on.
The n-tier design that most places follow doesn't necessarily apply here. For most of my pages, I define a query that I'll use in XML (entity query), then I'll inject it into my page action and call it there. So instead of having a controller, service, dao, and entity classes, you end up with simply a page action, the queries, and entity classes. You can cut out the service and dao layers in most cases.
Your whole definition of a service might change too. For me, a service is a service provider such as notification, security (auditing), exception handling, etc. all of these services run in the background and are not tied to a particular http request.
Walter
Daniel,
I have used one controller per page, one service and one dao per entity.
Use case logic goes in the controller
Entity specific business logic goes in entity service.
Actions which span multiple entities you can create a facade service - something which sits between controller and entity services
While the above is a good and practical approach, ideally:
you could break out any non MVC code from controller into its own service class, ie. 1 service class per page
you should only access the entity dao via the entity service.
Here's how the control would flow:
Ideally:
UI
-> PageController.java
-> PageService.java
-> EntityService.java
-> EntityDao.java
Practically, you could trim down a few layers:
UI -> PageController.java -> EntityService.java
Or for actions touching multiple entities:
UI -> PageController.java -> Facade.java -> Entity1Service.java,Entity2Service.java
PageController.java would be a Seam #Component and in your ui you can refer it as:
#{pageController} and pull the data from the view.
In architecture, the most important thing is how you layer things in the stack is avoid circular dependencies between layers. For example, Entity Service should not reference Controller and so on.
The other important thing is to be consistent about layering in the entire application. Use code generators if you can to keep your code consistent across the application, it really pays off for large projects. Look into Clickframes if you are interested in code generation (Clickframes generates starter code for Seam apps with full JPA/valdiation/security support which you can then modify). See this Seam demo build with Clickframes if interested.