i've build an web application, i have servlet as controler and java classes as the request handdler
so if the servlet receive an request from a client, it will call method from the request handler to process the request, and then the request handler will have to call an ejb to do the business logic, and when the ejb has done it process, the request handler will give the client an response(JSP Page)
so the question is, how to draw the UML based the stucture i've describe above? how to describe relationship between an component(servlet and ejb) with the pojo(requesthandler)?thx for help
is it right to draw like this?
http://i56.tinypic.com/2lmx6c5.jpg
thx
[per question in comment on how to draw class diagram]
Class diagrams are probably most often used for showing relationships in a problem domain. The relationships capture rules from the domain (e.g. "Each order consists of one or more orderlines" / "each orderline forms part of exactly one order").
In your case the classes span the layers of the architecture. Therefore the relationships capture architectural rules rather than domain rules. I don't tend to use class diagrams for that purpose, but the principle is the same. For each pair of classes you need to ask:
How would you describe the relationship among the classes?
What's the cardinality?
For example, take servlet & client. How would you describe the relationship? Probably something like:
description: client calls servlet / servlet is called by client
cardinality: for each given client instance, how many servlets can it talk to? Probably one or more. Similarly, how many clients can a single servlet instance receive requests from? Again probably one or more (will depend on your design)
Assuming above are correct for your design you'd have something like the following (apologies for the formatting, yuml.me doesn't seem to place text cleanly):
Same approach applies for remaining classes. First ask how you'd describe the relationship as a sentence, then figure out the cardinality. For example, take the servlet-request handler: how would you describe that? I'm not very familiar with java EE patterns, but would guess the servlet delegates to the request handler. So relationship phrase would be something like "servlet delegates request to request handler". And so on to ejb class, etc.
hth.
Related
Suppose we have are building a REST API for a job listings app where a user can apply for a job.
Instead of making JobApplication a nested URI resource like so:
It would be made a top-level resource:
Of course, in the case of the latter, the JobVacancy's id is still included in the request but is passed through the request body instead of the URI.
Why the latter approach? Because it saves the client the inconvenience of having to know the parent resource's id for 3 of the routes.
I believe that in the end, this is just a matter of standard. Both solutions will work fine, however, the first approach is more readable closer to the real-world operations, the applications are always related to some job vacancies.
Moreover, you need to consider if, in your system, you always access the applications starting from a job vacancy. If this is true, I believe that the first approach is much more clear, because the relation of dependencies between the two entities is clearly expressed in the signature of the method.
As mentioned in another answer, our use case for Webflow is a bit unusual. Instead of a traditional MVC approach driving UI, with a little effort we exposed SWF as a RESTful HATEOAS API (with some caveats). Our Views are Collection+JSON format with links modelling SWF transitions.
The problem is that SWF tightly binds to the MVC pattern of returning ModelandView, with the View states resolving a view and calling render(). As such till now our choices have largely been to expose the API via a JSP (yuck). We're looking to use Spring Boot (no JSP) and moreover use RestController and Spring Hateoas where instead we want to return ResponseBody<> or ResponseEntity<T> from a controller method, with that being an object formed from the View(state) - i.e. get the Model but no view and generate C-J or HAL+Forms or similar from it with transitions as Links.
We use XML flow definitions (essential to the solution) so I figure either I'd have to
Define a new Flow xsd with custom attributes and monkey with the ModelBuilder code and View implementation. Seems a lot of hackery.
Somehow define a do-nothing MVC view and defer to the customer controller for the HttpResponse when entering View, but how?
Write a complete custom FlowHandlerAdapter (this might help alter the POST-redirect-GET behaviour but won't tackle the ModelandView bit)
"Insert some more elegant answer here"
What is the best route to pursue?
Before this whole thing is considered lunacy, think what SWF brings to proper REST API exposure of business logic - not just another tedious boilerplate example of a CRUD repository API, but loosely coupled declarative workflow. I looked at Spring State Machine also but frankly it seems miles behind SWF on key aspects and doesn't help with state exposure as REST.
Symfony 3 - Should I create two different controllers for REST and normal HTML?
I already have a web application where I am using Symfony controller and twig html templates. So I already have the business logic written to fetch the content. Now I want to expose REST API to share this content with third party. Should I write a separate controller using fosrestbundle ? Or can I use the same controller for both json and HTML? If yes, how?
This might be a highly subjective question and each programmer will have another opinion to this.
I'll try to give you an answer ...
Is the REST Data requested by the page which gets already handled by the controller it might be a better choice to add just a simple json returning function for simplicity.
Are the requirements bigger and for example a third party application may have access to this, you should go with a dedicated REST API, since there may be complete different requirements for security, response times and so on.
At the one hand, a simple Controller can't give you that features and on the other hand it's much cleaner to follow the single responsibility principle with an extra API.
But consider also creating an extra API takes also more time.
So now you should decide yourself for now and for future whether you need an dedicated API or not. The need of third party access sounds to me to go for an extra API.
My question might seem strange for pros but please take to account that I am coming from ruby on rails world =)
So, I am learning ASP.NET Core. And I like what I am seeing in it compared to rails. But there is always that but... Let me describe the theoretical problem.
Let's say I have a Product model. And there are over 9000 records in the database. It is obvious that I have to paginate them. I've read this article, but it seems to me that something is wrong here since the controller shouldn't use context directly. It has to use some repository (but that example might be provided in such a way only for simplicity).
So my question is: who should be responsible for pagination? Should it be the controller which will receive some queryable object from the repository and take only those records it needs? Or should it be my own business service which does the same? Or should the repository has a method like public IEnumerable<Product> ListProducts(int offset, int page)?
One Domain-Driven-Design solution to this problem is to use a Specification. The Specification design pattern describes a query in an object. So you might create a PagedProduct specification which would take in any necessary parameters (pageSize, pageNumber, filter). Then one of your repository methods (usually a List() overload) would accept an ISpecification and would be able to produce the expected result given the specification. There are several benefits to this approach. The specification has a name (as opposed to just a bunch of LINQ) that you can reason about and discuss. It can be unit tested in isolation to ensure correctness. And it can easily be reused if you need the same behavior (say on an MVC View action and a Web API action).
I cover the Specification pattern in the Pluralsight Design Patterns Library.
For first, I would like to remind you that all such examples you linked are overly simplified, so it shouldn't drive you to believe that that is the correct way. Simple things, with fewer abstraction layers are easier to oversee and understand (at least in the case of simple examples for beginners when the reader may not know where to look for what) and that's why they are presented like that.
Regarding the question: I would say none of the above. If I had to decide between them then I would say the service and/or the repository, but that depends on how you define your storage layer, etc.
"None of the above", then what? My preference is to implement an intermediary layer between the service layer and the Web UI layer. The service layer exposes manipulation functionality but for read operations, exposes the whole collection as an IQueryable, and not as an IEnumerable, so that you can utilize LINQ-to-whatever-storage.
Why am I doing this, many may ask. Because almost all the time you will use specialized viewmodels. To display the list of products on an admin page, for example, you would need to display values of columns in the products table, but you are very likely to need to display its category as well. Very rarely is it the case that you need data only from one table and by exposing the items as an IQueryable<T> you get the benefit of being able to do Selects like this:
public IEnumerable<ProductAdminTableViewModel> GetProducts(int page, int pageSize)
{
backingQueryable.Select(prod => new ProductAdminTableViewModel
{
Id = prod.Id,
Category = prod.Category.Name, // your provider will likely resolve this to a Join
Name = prod.Name
}).Skip((page - 1) * pageSize).Take(pageSize).ToList();
}
As commented, by using the backing store as an IQueryable you will be able to do projections before your query hits the DB and thus you can avoid any nasty Select N+1s.
The reason that this sits in an intermediary layer is simply you do not want to add references to your web project neither in your repo nor in your service layer (project) but because of this you cannot implement the viewmodel-specific queries in your service layer simply because the viewmodels cannot be resolved there. This implies that the viewmodels reside in this same project as well, and to this end, the MVC project only contains views, controllers and the ASP.NET MVC-related guttings of your app. I usually call this intermediate layer as 'SolutionName.Web.Core' and it references the service layer to be able to access the IQueryable<T>-returning method.
Which on would be better in performance among Servlets2.5 and Struts2.
Struts2 uses Servlets underneath.
Theoretically Servlets will be faster than Struts2, however practically you may notice almost zero difference since the bottleneck in your app is least likely to be in your web-app framework.
Struts essentially means there is a default request handler, which
does some pre-processing for you and then calls the individual
controllers....
controllers then call the layer of models to setup the model and then
in a declarative fashion (views are configurable via the
struts-config) forward the request along with the value object
representing the model to the views for rendering.....
this is pretty straight forward - however if you need to make full use
of struts - like the forms,validation,error handling and resource
bundles etc.... at the minimum, you should be able to reuse the model
layer in its entirety without having to write one additional line of
code - IFF - you had designed it correctly in the first place...
with more details about your application - you'll find more help...
Struts2 is better than Servlets. As Struts2.0 has filter has a front end controller while struts1.2 uses Servlets underneath.
Struts2 has interceptor as a class which has inbuild validation. Struts2 has also its own library to create GUI. Struts2 also support OGNL language which is useful to prevent java code in JSP file. and Ultimately, its MVC architecture.