I cannot understand why Authority is so complex in JHipster? What's the reason for creating another entity with only one field name? Furthermore it has a csv file that uploads a template to the database with Liquibase.
There was an idea for me to create an enum (see this answer):
#Entity
#Table
public enum Authority {
USER, ADMIN;
#Id
private String title = "ROLE_" + name();
}
Then I decided that this is not necessary too. It can be an enum without annotations and just a Set (or even an EnumSet):
private Set<Authority> authorities = new HashSet<>();
Did I miss something? Maybe it's useful for JPA?
I wanted to create an issue on GitHub but I think it's a better place.
GrantedAuthority is defined by Spring Security and default implementation SimpleGrantedAuthority has only a role name but it can be extended to have more attributes so I guess that JHipster's entity enables this possibility.
Related
I was thinking about how to create a Proposal object like this in JHipster: so a User can create a Proposal and other users can vote for it.
entity Proposal {
proposalText String minlength(2) maxlength(100) required
proposalVotes Integer
}
entity Vote {
numberOfPoints Integer
}
relationship ManyToOne {
Vote{proposal(id) required} to Proposal{vote}
Proposal{user(id) required} to User{proposal}
Vote{user(id) required} to User{vote}
}
In Spring I would create that #Transient proposalVotes Integer and the Controller would go and find all the Votes that a Proposal has and add them together to get to the result to be sent to the frontend. That property would not be stored in the database.
If I use JHipster and I add a proposalVotes property, the result would be saved in the database and could be changed in the dialogs(... and I do not like the result), so my question is:
What is the best practice in JHipster when you need a property that is calculated everytime his object is called?
Think of the number of comments in a Blog with Posts, if it is more familiar.
Where do you calculate the result: I would do it in the ProposalResource, but I’m not sure and I haven’t seen any use case like this in the examples, but it looks like a common case.
Thanks a lot
PD: If there is any example in Github, that could be great!
Actually if you are generating entities using JDL(Jhipster domain language) then you wont get any option to make field Transient as JDL is database design mechanism and Transient fields are not going to be placed in DB.
Solution is that after importing JDL to our app you can add Transient fields in your entity class.
I'm using spring ldap with OpenDJ and was not able to set the attribute isMemberOf or memberOf for the person. Also, I'm having problem to get createdTimestamp and modifiedTimestamp attributes for the person. Please help
The createTimeStamp and modifyTimeStamp LDAP attributes are by specification Operational and read-only: they are set automatically by the server when the entry is created (LDAP ADD operation) or modified.
The isMemberOf is also an operational and read-only attribute in OpenDJ. It is a backlink between a Group and a user. It's computed on the fly, based on Static or Dynamic group. Add the user DN to a group, and you will be able to read the isMemberOf attribute in the user entry.
In my implementation, which currently uses Spring LDAP repositories (spring-boot-starter-data-ldap version 3.0.0-M3) and Oracle Unified Directory (OUD), I was able to fetch the operational attribute isMemberOf by simply including the #Attribute annotation on the appropriate user property.
For example:
#Entry(...)
public class AppUser implements UserDetails {
// ... other fields ...
#Attribute(name = "isMemberOf")
private List<String> groups;
// ... getters/setters ...
}
#Repository
public interface AppUserRepository extends LdapRepository<AppUser> {
}
By fetching a user with the repository's findOne() method, and without any additional configuration, it correctly populated the groups property. However, as mentioned in the other answer, it's read-only; to set the isMemberOf, you would need to add the user DN to any relevant groups.
I'm developing an application using domain driven design. One of the patterns I've been using is Repository pattern. For the sake of simplicity, let's say I have following classes and interfaces.
Car - domain class representing car domain concept.
public class Car {
public int Id {get;private set;}
public string SomeUniqueCode {get;private set;}
}
ICarRepository - interface for adding, deleting or saving changes to Car objects.
public interface ICarRepository{
Car AddCar(Car c);
void DeleteCar(Car c);
}
My problem is, how to check uniqueness of SomeUniqueCode property among all Car objects in the database? That property is changed by user (not auto-generated) at any time during the object life-cycle. Of course, one solution would be to put the unique key in the database, but that is not the principle of DDD. I've seen Specification pattern used to validate single objects. How would that pattern be applied to a set of Car objects?
Is it legitimate that Specification class (let's call it CheckUniqueCarSpecification) accesses ICarRepository?
A repository mimics an in-memory collection. What I have used before is a Contains method as opposed to a Find method, I guess you could have either. A query layer could also be used for this. Just as you have a CarRepository you could have a CarQuery. Trying to check for uniqueness in the domain is somewhat pesky. I would do a check for the sake of convenience but still rely on the DB to raise the exception since you should also handle that case. Using the specification pattern for this may be more effort than it is worth.
Since repository is a 'collection' I wouldn't have Commit and Rollback on there.
Use DomainService ICarCodesLibrary.
public class Car {
ctor(string someUniqueCode, ICarCodesLibrary codes)
{
// the check
codes.IsValidCode(someUniqueCode)
}
public int Id {get;private set;}
public string SomeUniqueCode {get;private set;}
}
Implement the interface in the place where u create the Car object and inject it. Also get rid of the properties and use fields. The ID is OK to be a prop.
After through search i was unable to find any question which answers this, in my opinion fairly common design problem.
Given domain object:
public class Item {
private Long itemSN;
private String name;
methods, etc...
}
We need to store specific set of String properties which describes an item. It can be weight, color, sizes etc. System must be flexible and able to persist changeable list o properties. It needs to store allowed properties names, and preferably enforce some of them.
I tried several approaches, but concept of common constraints shared by all Item objects just don't fit in any standard domain model.
So i started to think about constraints as a form of configuration. Each Item has its's own properties (in simple String Map), constraints at the other hand are common configuration for all Items. So the next dilema emerged... how to express it without making big hole in domain model ?
It's easy to introduce additional application layer object to store constraints, but "allowed/required properites" are business affair, we need to allow domain user (manager of some sort) to change it, so its feels really horrible to draw this logic away from domain layer.
Any suggestions are welcome.
Edit 1.
After lot of brainstorming i managed to create valid object model for given situation. From first sight it was impossible to encapsulate properties with common constraints, but the latest out-of-domain implementation gave me an idea:
public class Item {
private Long itemSN;
private String name;
private List<Property> properties;
}
Core of the problem was solved here:
public class Property {
private Long propertyId;
private String propertyValue;
private Constraint constraint;
}
public class Constraint {
private String name;
private Boolean required;
private List<String> allowedValues;
}
So, each property have its value and constraint object which specifies name, allowed values and required status. This way constraint object can be shared by many properites, and any of this properties can have its own value.
It's adding some complexity to DB mapping and will hit performance but it's also keeping all domain logic in domain objects.
Any improvements, suggestions and opinions are welcome.
This problem can very reasonably be solved by the usage of annotations. Annotations allow you, the coder, to keep on using the language for the usage of properties by simply annotating your properties with constraints while still making it possible to apply the same constraints to user defined fields without the annotations.
JSR-349 is a Java standard for applying such constraints. Hibernate validator is a well known implementation.
Is it possible for an Aggregate root entity to have a method in which it will call a Repository?
I know it should not but want to get confirmed as Eric's book is also not saying anything clearly :(
one more thing where can I get a unit testing example for domain-driven design?
This is a bit of a religious question.
Some see no problem with this, while others might believe it is heresy to do so.
While I've normally always kept my Repository away from my Domain Model (and had an upstream service object deal with the Repository), I have had a project that "required" having the Repository accessable from the Domain Model.
This was due to the Domain object needing to retrieve specific data based on business logic => using specification objects/Linq to nHibernate (the responsibility and knowledge of how to filter data belonged to that Domain Object) and/or performance reasons.
A caveat around doing this is how to get the reference to the Repository to the Domain object - in that case I utilized Constructor injection with an IOC tool.
Whether you should do this or not really depends on your solution/use case/technologies being used etc...
Can? -Yes.
Should? -No.
All answers are however context-sensitive, and you don't provide yours.
A generic advise would be to look for a "service" or "specification" type.
Behavior IS-WHAT-IT-IS. Eric calls a Repository like utility from a Brokerage Account entity called, "QueryService". He mentions that it's not a good design for a real project. So what do you do?
public class Clerk
{
public Clerk()
{
}
//Store Report in Database
public void File(Report);
{
ReportRepository.Add(Report);
}
}
You could do that, but it's probably best to tell the Clerk which Repository to use.
public class Clerk
{
private IReportRepository _reportRepository;
public Clerk(IReportRepository ReportRepository)
{
this._reportRepository = ReportRepository
}
//Store Report in Database
public void File(Report);
{
this._reportRepository.Add(Report);
}
}