Prosty test jednostkowy, czy poprawnie zachodzi proces serializacji do JSON`a i czy jest dobry status,
Testowanie mocka z mockiem wydaje mi się tak samo bez sensu, jak rzucanie wyjątku, kiedy Optional jest "non'em".
private void checkIsNotPresent(Optional<Company> optional, Long id){
if(!optional.isPresent()){
throw new ResourceNotFoundException("Company[id:" + id +"] was not found.");
}
To jak to poprawnie nazwać ? Założyłem, że skoro coś jest oznaczone przez adnotacje @Entity to jest to encja. Korzystam z relacyjnej bazy danych, ale nie jest to moja domena.
A no fakt jest tam logika biznesowa. :)
public void addCar(Car car){
if(this.cars == null) this.cars = new ArrayList<>();
car.setDepartment(this);
this.cars.add(car);
}
Wiec nie można powiedzieć, że nie jest to DM.
Ja bym wolał po prostu operować na presistance objects z DAO. No, chyba że ta warstwa domenowa to jakaś inwestycja na przyszłość.
Tego akurat wydaje mi się, że nie. Jest to specjalnie tak napisane by przypisywało tylko co nie jest nullem. Dzięki temu jak przekaże tylko część parametrów w JSON`ie to tylko ta część zostanie zmieniona. Taki był mój cel.
Nie można tam użyć Optionala z 'Map'.?
Dlaczego? Wydaje mi się, że wszystko idzie według dobrego schematu i na siebie nie nachodzi. Controller odpiera DTOSy > Service mapuje > Repo zapisuje. Jest wiele DTOsów, co mogło popsuć czytelność, ale schemat jest chyba w miarę dobry.
Tworzenie modułów per nazwa wzorca lub czegoś, co nawiązuje do używanego języka jak np. "Interfaces" zawsze jest złe.
Najpierw zawsze powinno występować powiązanie logiczne modelu.
np.
Departaments
---DepartamentSrvice
---DepartamentDto
---Cars
------CarsDto
------CarsService
Nie musisz też wszędzie używać nazw 'Service' często zabija to kreatywność i pogarsza czytelność modelu. Czasem lepiej jest napisać to co ta usługa robi.
np. Zamiast BoxService możesz napisać PackingBox.