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
I am writing my persistent classes for a Java EE 6 project.
I am seeking best practices in writing these classes.
For example, i know that adding version field is recommended.
I am waiting for your help. Merci
UPDATE 1:
I am writing classes for an ecommerce: persons, products, reviews ....
That really depends on what are the requests.
Adding fields just because it is "recommended" may hurt performance, as they are mapped to columns at DB.
Maybe your flow does not require "versioning" at all?
What I would like to suggest for you is (if you insist on using JPA/Hibernate) is:
A. Think of your business logic entities - for example, if this is an application for a library, entities may be - Book, Author, Shelf, Room, Librarian, Reader, and so on...
B. Model the relationships between these entities - For example - a Book may be written by several author. Each other may write several books
Once you're done with this Java/OOP modelling, move on and intorduce relationships, based on JPA annotations:
For example, for the above book author relationship you will need the #ManyToMany annotation.
At this point you will also need to define what are your primary key columns.
You should also consider whether an entity which is used once per each other entity instance - for example - an Address will be used once per Reader, should be kept in a separate table, having OneToOne annotation, or will you prefer to keep it at the Reader table, using an Embeddable class.
However, the best practice can really change when it comes to the domain of the application, the required performance and the use cases.
I would suggest you to start building/designing your application and ask more specific questions.
If you are using JPA in your application, you should need to understand EntityManager and Relationships at least. See this link to learn the usages of JPA. It may be helpful for you.
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 3 years ago.
Improve this question
I have a monolithic app that does the following logics:
Get a list A (Customer) from database
Validate data in A using some criteria, if it's not validated, throw an error
Do some operations on A to get a list B (e.g. Regional customers)
Do sth with B
Now I am transforming my app using microservices, but I have trouble in designing the calls.
As B can be deduced from A entirely, I want to just make a single micro service getCustomerA that returns all the dataset A. That means a single database access is needed. That will be a performance plus.
But the problem is, the operations on A to retrieve list B is also part of the business code. So it's more logical to put these codes in Customer microservice side, if we follow domain driven design, in microservice Customer, maybe getRegionalCustomer.
So I want to know, what is the best practice in this case ? Should we priotize the single database call (first case) or it's better to do two calls (but in this case, 2 database calls) ?
Since this is mainly opinion based I can only give you that :-)
From my experience splitting the app into microservices just for the sake of doing it puts technical dogma over technical simplicity and often introduces a lot of unnecessary overhead.
With regard to the database calls I can also tell you from experience that quite often you win performance when doing two simple calls over doing one overly complex one. Especially if you start introducing big joins over many tables or - ouch - subselects in the on clause.
See if the most simple solution works and keeps the code tidy. Constantly improve quality and optimize when the need for it arises. If you have a piece of logic that warrants to be split of into a microservice (e.g. because you want to use a different language, framework or want to offload some calculations) then go for it.
Domain driven design does not tell that each boundle context only can contains one entity, in fact, a bounded context (or microservice) can contains more than one entity when these entites are clearly related, in other words, when they need to be persisted transactionally.
In your case, due to the tight relation between the two entites, the best way is to build only one microservice that do both operations
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 8 years ago.
Improve this question
I currently have several "manager" classes in a project I am working on but have seen a lot of things that advise you to not use manager classes but don't seem to provide any alternatives in my situation. I have a ClickManager which contains a map of "clickable" objects and a ConfigManager which is responsible for loading and saving config files as the config class comes from an API I am using and is too stupid to load itself.
What are some alternatives to using "manager" in these cases?
Ward Cunningham once said (1) that every programmer should have a dictionary and a thesaurus on his or her desk. There's also a saying that there are only two hard problems in computer science: cache invalidation and naming things. (2)
The point is that naming things is important, and it's hard, and it's often neglected. This is why there are classes named Data and Manager littered around many code bases.
There are at least two potential things going on here. One is that the class is doing something reasonable, and it just needs to have a good, concise, descriptive name applied to it. For example, with ClickManager, does it dispatch events to the clickable objects? If so, maybe it's a Dispatcher. Does it lay out the clickable objects? Maybe it's a Positioner. Does it contain the clickable objects (as Erwin Bolwidt suggested)? Maybe it's a Container. Does it execute something in response to a click? Maybe it's an InteractiveCommand. It's sometimes helpful to think more specifically about what a class is doing in order to come up with a good name.
Another possibility is that the class has too many responsibilities, that is, it violates the Single Responsibility Principle. This is often the reason that something is hard to name, because it does a bunch of different stuff. Suppose the class simultaneously contains clickable objects, dispatches events to them, positions them, and executes commands. It's no wonder that it's hard to come up with a name other than Manager because it's doing all of these related, but independent functions. (Note that in many UI toolkits, these responsibilities have been separated into different classes.)
If this is the case it might be advisable to do some refactoring of a big Manager class into smaller classes, each of which has fewer (or one) responsibilities. It should be easier to come up with better names for those classes.
(1) I think it was at an OOPSLA about ten years ago.
(2) And off-by-one errors.
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 8 years ago.
Improve this question
I need to persist objects and I want to keep my data classes as clean as possible. The persisted classes do not feature any business-logic code, but only data with getters/setters.
I'm currently implementing a solution with the Observer pattern. Each time an Observable persisted object is modified, it fires a message to an Observer object that takes care of persistence. This way, the only constraint for the persisted object is to be "Observable". It keeps things clean.
Another solution (maybe better?) would be to implement some DAO pattern, and I'm not very aware of the way it works. Maybe it would look like persistedObject.save(); or persistedObject.readById(id);. But it means I would have to define some DAO interface and then to implement the read/create/update/delete method in each and every persisted class
There are many, many, many answers to this question, data serialization or persistence is a core problem in software engineering. Options include using databases, memory mapped files, binary and textual formats, and more.
My personal favorite for quickly persisting objects is GSON, however your use case will dictate what works best for you.
You mention wanting design patterns for persisting Java objects, and while such patterns are approximately as numerous as there are libraries, here are a couple general suggestions:
Use immutable objects
Use the transient keyword for any fields that are not necessary to reconstruct an object
Avoid defining sanity checks or otherwise limiting the range of acceptable values in your objects - an instance constructed from a deserialize call may not correctly trigger your checks, allowing possibly invalid objects to be constructed
Use your serializable objects to construct more complex objects if you need more sanity checking, e.g. serialize a StubPerson POJO, and have a Person object that can be constructed from a StubPerson only as long as the stub's values are valid
I don't know if it fits for you but since you have only bean classes you could use the Java persistence api.
The DAO pattern is the best one to manage data access and persistence as it has been designed specifically for that.
Considering your needs you will probably have to couple it with some factory pattern in order to manage the different implementations (persistence adapters).
I don't know your requirements but if your application can be used by many persons at the same time you will have to care about concurrent accesses and define a policy (transaction, locking, etc... otherwise people will overwrite data each others).
Regarding your question i'd suggest JDO (with data nucleus as implementation) but the learning curve may be too expensive for your effective needs.
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 6 years ago.
Improve this question
My team has been tasked with creating what you can generically call an entity management application. The 3 primary entities being managed are: Merchants, Organizations, and Contacts
Separate pages have been created for the management of each entity. However, many of the functional patterns on these pages are quite similar. The 2 patterns in particular that are repeated everywhere I look are:
Pattern 1: Associating entity of type Y with entity of type X
Pattern 2: Listing entities of type Y that are already associated with entity of type X
Unfortunately these pages were created adhoc by multiple developers. This has resulted in a hodge-podge of solutions, none of which are readily reusable. So what I want to do is abstract out the two patterns I identified above into reusable components, but I am fairly new to wicket and I'm unsure of the best strategy to use.
My first thought is to encapsulate the patterns in two parameterized component classes that extend panel. But I would like to hear from those with more experience.
Any suggestions?
EDIT:
Forgot to mention, for any wondering, that any of the 3 entities can associate in a many to many relationship with either of the other 2.
Sounds like a pretty good idea to me. Additionally I'd check if any specific logic (like DAOs, Validators and stuff) could be provided via Dependency Injection (Google Guice comes to mind) so you could just use one panel with different handlers/workers/dataproviders for your different usecases.
It's hard to be more specific since your question is kind of broad and a little bit on tue vague side..
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 6 years ago.
Improve this question
I just wrote a long (and messy) blogpost about my view on domain-driven design at present day, with frameworks like spring and hibernate massively in use.
I'd ask you to spot any problems with my views on the matter - why this won't work, why it isn't giving the benefits of DDD, why it is not a good idea in general.
The blogpost is here (I don't think I need to copy-paste it on SO - if you think I should, tell me).
I know the question is subjective, but it is aimed at gathering the most predominant opinions.
(I'm tagging Java, since the frameworks discussed are Java frameworks)
I've just spent a year of my life ripping apart an application to eliminate an anaemic domain anti-pattern and its mis-use of Hibernate.
I can say without a doubt that the code that comes as a result of DDD is much easier to understand and refactor. In our case, the removal of a myriad unnecessary getters & setters, the increase in encapsulation, the concentrating of business logic, and resulting (dramatic) simplification of the services layers that come along with DDD have made the system so much more easy to maintain that now I believe we will be able to finish it, whereas before it was dragging on into forever. We've reduced the line count of this application by 50% without removing any functionality.
I also believe that the entire point of an ORM tool is so that my business logic is uncluttered with persistence code. When we had an anaemic domain model, we had a DAO for every domain class, now we have a small handful of DAOs as an entry point for CRUD on the "major" domain classes, but the other "minor" domain classes are handled by their parents...not because persistence logic is in the parent but because Hibernate transparently reacts to the business logic and makes everything Just Work.
In short, I can't answer this SO question because I emphatically agree with your post 100%...and am living it every day.
We go with the "anemic model" approach so that we can reuse the same models with different business logic. However, we do include calculations and helper methods within our models if they're applicable for all cases. But we do not inject anything into our models and do not inject our models into IoC.
Personally I'm not convinced that the part about injecting repository objects into the domain objects (meaning the persistent entities) is necessary with Spring and Hibernate. Hibernate is already providing persistent collections that can do lazy loading, so you already have the ability to traverse the domain model in a way that separates data-access infrastructure from business logic. I don't see what value tacking repositories onto the domain model is adding.
EDIT: Oops, posted this before reading the whole article. Now that I've read the entire blog post I think I'm in agreement with it. I like the part recommending doing without DTOs wherever possible.