I have a web application in Servlets and JSP. Now i need to add some additional functionalities to a couple of service methods in it. Service methods those needs these changes are from different servlets.
Additional functionalities are as follows.
Validating status before its core function.
Notify respective users on successful completion of that process.
How can I inject these functionalities to existing code with minimum overhead?
I think AOP in spring can help here, but i cant use Spring in existing application for this feature.
Also tried to use decorator pattern, but i couldn't as each service class contains multiple methods, also there is no common interface for them.
Can someone let me know how to handle this change in a better way.
Also tried to use decorator pattern, but i couldn't as each service
class contains multiple methods, also there is no common interface for
them.
As you are stating that there is no common interface, you can use Adapter Pattern which is the best fit when you have problems with service interfaces. Basically, adapters help to interact with two services with no common interface. You can create an adapter (layer) which handle the additional functionalities (i.e., Validating status and Notify respective users, etc..) by invoking the existing services.
Below is the wikipedia definition for adapter pattern:
the adapter pattern is a software design pattern (also known as
Wrapper, an alternative naming shared with the Decorator pattern) that
allows the interface of an existing class to be used as another
interface. It is often used to make existing classes work with others
without modifying their source code.
Related
What are the differences of using Spring Data REST repository alone and implementing the “service” pattern around it (that is ItemService, ItemServiceImpl and so on)?
At the first glance the functionality is more or less the same with the difference that the service approach allows for a better customization but it also produces loads of boilerplate code (the implementation and the controller). Here is an example (look Payment and CreditCard entities) of using both approaches - RESTBucks of Oliver Drotbohm.
The payment abstraction there uses the "service" pattern used (PaymentService, PaymentImpl and then PaymentController with all methods in web folder) while the orders are exposed via Spring Data REST directly.
tl;dr
The payment functionality lives at a higher level of abstraction as it doesn't follow established HTTP resource patterns (collection resource, item resource, in general: the ones described here) and thus warrants a custom service implementation. In contrast, the lifecycle of the order aggregate does indeed follow those patterns and thus doesn't need anything but Spring Data REST exposure plus a few customizations. Find a conceptual overview about how the two implementation parts relate to each other here.
Details
That's a great question. The sample application is designed to showcase how different parts of an API can be driven by different requirements and how you can use Spring Data REST to take care of the parts that follow established patterns but at the same time augment it with higher level aspects that are needed to express business processes.
The application is split into two major parts: the order handling that's centered around the Order aggregate that is taken through different stages. A conceptual overview about those can be found here. So parts of our API for the orders will be following standard patterns: filterable collection resources to see all orders, add new orders etc. This is where Spring Data REST shines.
The payment part is different. It somehow needs to blend into both the URI and functional space of the order handling. We achieve that by the following steps:
We implement the required functionality in a dedicated service. The repository interaction doesn't match the necessary level of abstraction as we have to verify business constraints on both the Order and Payment aggregates. That logic needs to live somewhere: in the service.
We expose that functionality via a Spring MVC controller as we (currently) don't need standard patterns like listing all payments. Remember, the example is centered around modeling the ordering process, it's not an accounting backend. The payment resources are blended into the URI space of the orders: /orders/{id}/payment.
We use hypermedia elements to indicate when the functionality can be triggered by adding a link pointing to those resources conditionally so that clients can use the presence or absence of those elements to decide what UI affordances to offer to trigger that functionality.
Here's what I think is nice about this approach:
You only manually code the parts that are important from the business point of view. No need to implement a lot of boilerplate code for the parts of the API that follow well established patterns.
Clients don't need to care where exactly that seam is. Using hypermedia elements, the API just looks like one thing to the client. The server could even move the payment resources to a different URI space or a different service even.
Resources
This deck discusses what I described in detail. Here's a video recording of it. If you're interested in the higher level ideas of especially the drive towards hypermedia, I suggest this slide deck, too
Your service contains all the logic, but the repository layer is as stupid as possible. Its task is a specific operation(for ex. save, edit).
Spring Data is an additional convenient mechanism for interacting with database entities, organizing them in a repository, extracting data, changing it. in some cases, it will be enough to declare the interface and method in it, without implementing it.
P.S
and it's a good choice if you're creating a simple crud
I checked out this SO Post which discusses using RequestMapping in interface. Although the post contains ways to achieve this but it does not mention the pros and cons of doing this.
Architecture wise , is this a bad idea to use controller as interface?
What benefit will we achieve in terms of polymorphism for controller?
There is nothing wrong with putting #RequestMapping on the interface. However make sure you have the right reasons to do it. Polymorphism is probably not a good reason, you will not have a different concrete implementation swapped in at runtime or something like that.
On the other hand, for example, Swagger codegen generates interfaces with #RequestMapping and all the annotations on the methods, fields and return types (together with #Api definitions etc.). Your controller then implements this interface. In this case it makes a lot of sense because it is just enforcing you to respect the Swagger / OpenAPI interface definition originally defined in Yaml. There is a nice side-effect that it makes your controller much cleaner. (Clients can also use the same Yaml to generate their own client stubs for their own language frameworks).
If you opt to do this, make sure you use the latest version of the Spring Framework, because there were some bugs which were fixed only very recently, where not all annotations were being inherited.
https://github.com/spring-projects/spring-framework/issues/15682
If you are stuck with an older Spring version, you might need to repeat the same annotations in your controller.
So, the real reason this would make sense is to enforce the interface contract, and separate the interface definition (together with any information pertaining to the interface) from the actual concrete implementation.
While some arguments against this are that
the request mapping is an implementation detail, or
since you only have one active controller implementation, you might as well put it on the implementation,
(others will probably be provided in different answers soon,)
I was recently faced with the same decision to put jax-rs annotations on the interface or the implementation. So, since everything always "depends" on some context, I want to give you an argument for putting the RequestMapping (or e.g. #Path, etc if not using spring) on the interface:
If you are not using HATEOAS or discovering the endpoints via some other means, the endpoint url, http method, etc. are usually fixed and a static part of your backend API. Therefore, you might as well put it on an interface. This was the case for me because I control both the client and the server side.
The controller usually has only one active implementation, so the reason for doing so is not polymorphism. But your implementation usually has a lot more dependencies than the plain interface. So if you export/provide only your interface to clients (e.g. in a seperate jar/java project/...), you only provide things that the clients really require. In my specific case, I delivered the annotated interface so that a client implementation could can it using a Rest-Client-Library and detect the endpoint paths automatically.
I'm creating an android library and wanted to organize with layers it something like this.
PublicClassExposedToLibraryConsumer.java
logic.PublicFooLogicInterface1.java
logic.PackagePrivateFooLogicClass1.java
logic.PublicFooLogicInterface2.java
logic.PackagePrivateFooLogicClass2.java
domain.PublicFooDomainInterface1.java
domain.PackagePrivateFooDomainClass1.java
domain.PublicFooDomainInterface2.java
domain.PackagePrivateFooDomainClass2.java
repository.PublicFooRepoInterface1.java
repository.PackagePrivateFooRepoClass1.java
repository.PublicFooRepoInterface2.java
repository.PackagePrivateFooRepoClass2.java
1) I want a number of layers and I want to limit interaction between those layers by using interfaces.
2) I want to only expose PublicClassExposedToLibraryConsumer.java to the consumer of the library. They should not be able to access the other classes and interfaces.
Is this possible? From what I've read in order to make something accessible to something consuming the library it needs to be public and to hide something from the consumer of the library it needs to be not public. By my reading this means that you can't separate layers without exposing something and you can't hide internal classes without being forced to use a completely flat architecture. I find this very hard to believe, I have to be missing something.
You can try with annotations providing specific scope for your desired file to restrict to end-user of your library. Best way to do this in Android is using #RestrictTo support library annotation on class level.
Note : For Fields and Methods of particular entity can be scoped with access-modifiers like private, protected or package-protected etc. *(Just ignore if you already know that)
#RestrictTo : Denotes that the annotated element should only
be accessed from within a specific scope (as defined by
RestrictTo.Scope).
In our project architecture we are using a classic MVC pattern including a classic service layer (opening the transaction and calling the DAO layer).
For each service we have an implementation and his interface. But to be honest, I'm pretty sure that for one service and his interface, we will never have more than one implementation. So ok maybe it's more clear to have the public method declared in the interface helping to know what the service does, but an interface is used to have multiple implementation and if we know that we won't have more than one implementation, should we keep them?
From the documentation:
Implementing an interface allows a class to become more formal about
the behavior it promises to provide. Interfaces form a contract
between the class and the outside world, and this contract is enforced
at build time by the compiler.
If you know that you will only have one implementation, the implementation itself will define the contract, so you can remove the interfaces.
But writing an interface could help you to better define the contract and also, you could need at a given point to write a mock for the service, in such a case you would benefit from the use of interfaces.
i think this is a good approach for keeping interfaces.
reasons:
1. say you want to write junits for the same with a different implementations ex. inspite of getting data from database you want to get data from a separate datasource then a different implementation will suffice.
I'm working on a project with Spring Web Flow to manage some configurable flows.
My main question is: is it possible to extend the framework with custom classes and extend the spring-webflow-2.0.xsd?
We need to change the default behaviour of Spring Web Flow to achieve the following goals:
Extend the spring-webflow-2.0.xsd in order to add custom elements we need within the "states". And so, extend also the XmlFlowModelBuilder class in order to parse these new custom elements.
We need to be able to set a custom builder (like flow-builder inside flow-registry) which reads several XML resources, each one with its own id, like flow-location-pattern does. So we need a kind of mix between both ways to define a flow-registry. In addition, we would like to get those XML flow definition files from an external source (eg, with a service), and auto-rebuild the flowModels when some of those external XML changes.
Is it possible? We have found out that the flow-registry element creates a FlowRegistryFactoryBean, which has the main method calls. We would like to customize the class but this is not possible since it is a private class. We cannot even create a bean with this class.
So how could we make these customizations?
As in any other case of using the java library, you can extend and compose the classes from spring-webflow packages.