Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I wants to develop service layer for my application using java. At the same time the service layer can also be exposed to webservice also.
My idea is to create one Generic Abstract Class for database operations , and all other service classes extend that abstract class and do the DB operation through that abstract class methods.
Is this a good idea to do it?
Please help me
It's hard to say with so few details, and without even knowing what you'll use to access the database (JDBC? JPA? Hibernate?). But
the service layer and the persistence layer are not the same thing. To ease decoupling and testability, I prefer having a pure service layer and a data access layer
inheritance is generally not the best way to reuse code. Use a well-design API, and prefer delegation over inheritance.
Also, don't reinvent the wheel. EJB3, Spring and other frameworks have good support to develop services and expose them as web services.
You should consider using some framework, which will help you with routine. E.g. Spring or Java EE. Those frameworks can offer you many built-in solutions like IoC, declarative transactions, declarative security etc.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I recently started reading a book that explains in more detail the manipulation of databases, in terms of the relationships between them, especially. The problem is that this book is a bit old, from 2014. So I come with the following questions, to which you can clarify, please:
In the book we use Dao, Dto and Service pattern, but we can't use JPA, Spring Boot Repository or other new technologies to "replace" the old implementation that the book presents?
If so, can you give me an alternative to the code below, and how does it work? What could I improve, what could I give up, what should be completed, what should I learn, please!
Book divide the implementations of an Application in 2 teams:
UserInterface (Data Transfer Object of the entity, singleton in Memory DB and Controller as Mock Service and view)
Development Team (with creating the Entity and testing using TDD, creating DAO for that Entity, Business Service Tier and Presentation Tier
So, I can change this way of creating and manipulating the applications and Databases, if yes, how, and why? What should I use, how should I do it?
This is the git of the book I'm currently reading: https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src
As far as division of labor, the concept of having a separate team work on the controller layer seems antiquated. It could be that the single-page-UI has its own team, but many places prefer that the same people work on everything for a feature front to back, in order to reduce opportunities for communication problems between teams.
The extent to which you need DTOs should be up to the developer's discretion. It used to be a practice to routinely copy all entities into DTOs to avoid issues like lazy-loading in the UI. If you are building a single-page application where you're passing JSON to the UI that isn't an issue. The single-page application architecture provides better separation between UI concerns, making DTOs less necessary in most cases.
For the rest of this the concepts should map over. A Spring JPA repository has the same function as a data access object, it just provides more of the implementation for you. The biggest change associated with the Hibernate mappings is to use JPA annotations instead. Services haven’t changed.
TLDR
things that have changed:
single-page applications have replaced serverside approaches like JSPs
standardizing on JPA instead of Hibernate
configuration classes, no application context XML anymore
profiles
focus on microservices vs. monoliths
more batteries-included (h2 by default, deployable jars, convention over config)
things that haven't changed:
general layering scheme of controllers calling services calling data access
Hibernate mapping strategies and general ORM issues
Spring transaction support
general Spring programming model with beans, DI, AOP
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
When building an API RESTful webservice which performs CRUD operations, is it a right practice to synchronize the methods? Or should we avoid synchronizing the methods since it reduces the performance.
Could anyone please explain.
It is not "right practice" or "best practice".
It doesn't even make sense to me. In general.
A RESTful API consists of a URLs for making http / https "calls". The notion of "synchronized" is foreign to this.
Now a there might be use-cases where it would make sense to use some form of mutual exclusion in the implementation of a RESTful API. However, it is not clear that declaring Java API methods as synchronized gives the correct semantics. Certainly not without knowing how your RESTful API is being mapped onto your Java methods and your domain objects.
If we are talking about mapped Java methods in a Spring #RestController class, declaring those methods as synchronized would result in mutual exclusion on the current instance of the controller class. Spring controller objects are singletons, so you would end up processing your RESTful requests serially. I can't see why you would want to do that.
The correct way to approach this is to work out what you are actually trying to achieve, and then look for ways to achieve it. Don't go looking for a solution before you understand the problem. And don't look for "best practice" justifications. Think things through ... in the context of your problem.
There are no best practices.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need some guidance in designing an API wrapper for my backend APIs. I have tried to keep it as specific as possible.
Context: We have a project which supports certain file operations like edit, create, merge etc. All the services are exposed as rest APIs. Now I have to create an API wrapper over this (client library) in Java. I've been reading about DDD and trying to approach the problem using that.
As per my thinking, the core object in my project would be File, along with some minor DTOs for talking to the backend. Edit, create, merge will be the verbs here acting on my domain object. I want to make it as easy as possible for the external developer to integrate the API. I would like the design to be something like that
For Creating a file : File.create() For editing : File.edit() Same for other operations Also, I want to have the capability of chaining operations (along the lines of fluent interfaces) for readability
For. eg. if you want to create a file and then convert it, it should be something like : File.create().convert(Required params)
My problem is each of the operation is bulky and async. I don't wanna write all the async error handling logic in the File class. Chaining the methods like above wont be easy as well if they return CompletableFuture objects, and this will be harder to maintain.
Question: What is a better way of solving this problem?
I am not looking for a spoonfed design. I just want to be guided to a design approach which fits the scenario. Feel free to point if I am understanding DDD wrong.
Very roughly: your domain model is responsible for bookkeeping. The effects on the state of the filesystem are implemented in your infrastructure layer, and you send the results back to the bookkeeper.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
we are creating an appraisal system ,in which there will be a no. of validations and computations. Team leader decided to use web services for most of their logic ,which we are going to write.
I am just curious ,when we can moreover when we should web services and when we should avoid using it?
The team leader decided to use web services for most of their logic.
I would not advise putting the logic in web service code. Put it in a business logic layer, that can then be exposed via, for example, web services.
When should web services not be used?
When they are unncessary - without a specific scenario it's difficult to give a more meaningful answer.
Avoid using web services for method invocations that can be resolved locally (on the same JVM). Otherwise, use them.
Web services are the best/easiest way to do distributed operations. For example central server and many clients. If you have that sort of architecture then you need either web services or a web application.
If everything is stand-alone and local though then you don't need them and they will be less efficient than just doing things directly.
Web services and web application..
web services provide a standard means of interoperating between software applications.
When all major platforms could access the Web using Web browsers, different platforms couldn't interact. For these platforms to work together, Web-applications were developed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My system is connecting to Oracle through Hibernate/JDBC. I want to restructure it using abstraction to decouple its implementation from Hibernate library. That's a backup for someday the team can switch to another JPA implementation without painful to change core business logic to adapter with new JPA implementation. What are advices in doing this?
By the way, I want some advice from gurus what are common practices/tactics to decouple existing projects from external open source jars?
Direct dependence on standard and popular open source libraries is OK. You shouldn't consider it as a problem. For e.g I have a large code base and it depends upon joda-time, google-guava etc. Now, coming to your situation, following is my view point
There is very less chance that you move from one JPA implementation to another because by the time you get familiar with a particular implementation (yes implementation because you might want to optimize something or you are looking for some feature that is missing from standard JPA api) it would take some time and you really doesn't want to spend the same effort learning other implementation (business doesn't let you even if you want to ;-)).
Spring already abstracts most of the regularly used API's like JPA, JMS etc. so I suggest you look at that option.
You should program against interfaces to reduce dependencies. Your service classes -the ones that contain Business Logic- should depend on Data Access Object Interfaces instead of an specific DAO implementation. Something like this:
public class ImAServiceBean {
private EntityDAO entityDAO;
private void someBusinessLogic(){
entityDAO.createInstance(...);
Were the DAO interface goes this way:
public interface EntityDAO {
void createInstance (...);
void updateInstance(...);
Now you're using something like EntityHibernateDaoImpl, but if you want to change your persistence framework to MyBatis you can build an EntityMyBatisDaoImpl (which implements EntityDAO) and use that class in your Services classes with no change at all (asumming you're using some kind of dependency injection). The same thing if you use JPA, JDO or any persistance technology: your Business Logic only depends on a plain interface, and that interface can be implemented but any persistence technology, even JDBC
JPA already is a separate API. if your team uses JPA, then you should already have the ability to switch from hibernate with zero effort.