Timeline for Architecture review - case study (Spring MVC)
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot | replaced http://stackoverflow.com/ with https://stackoverflow.com/ | |
| Aug 29, 2016 at 6:43 | comment | added | Walfrat | This feel somewhat really generic, i'm not good enough for this, the only thing i see is the controller part. There is very likely a chance that you need some process in the Controller to adapt data. But you should be able to not have anything else. Finnally if you make DAO totally independant and abstract, DON'T USE LAZY-LOADING, or you're going to be in trouble. As said the answer i linked, for an efficient use of lazy-loading and JPA, service layer must consider that they have JPA entities and use them as such. | |
| Aug 26, 2016 at 19:49 | comment | added | Loa | @Walfrat I just edit my question. Can you take a look, please? Thank you, again! | |
| Aug 25, 2016 at 7:00 | comment | added | Walfrat | @Loa as i said, i use lazy-loading, but most of my entites in fact use eager fetching. But when you have somewhat a complex class which is a top of a relationship, you may trigger a lot of database hits if you're doing it wrong. This can be improved with strict coding practices. : the most important phrases of the article in my opinion. Devs have really to know what they're doing. And of course don't load 4 levels of relations when it isn't necessary, but that's a matter of code, not entities design. IMHO people are having probelm with ORM because of (stupid) code, not so much in design. | |
| Aug 25, 2016 at 6:51 | comment | added | Walfrat | @Loa Well that's a special case, and i have that too. For this very case, i use a special wrapper class which will contains only the needed fields and use the Criteria.multiselect() or the jpql syntax select new com.foo.bar.MyDTOClass(a.field1, ...) from .... Same when i need to be able to send some form data into a JSON, i have a dedicated wrapper class that will contains the fields or business objects needed for the process. So i do have some DTO classes, but i don't have any adapter, translator. | |
| Aug 25, 2016 at 5:11 | comment | added | Loa | @Walfrat So you're saying/recommending that I should not use DTO, and to leave my SERVICE, DAO, and CONTROL components just working with the Domain Model entities? And what if my view need to display a summary of data, which may be present/spread in N different Domain Model entities? Indeed, writing DTO may involve writing double or triple code, which also involves writing a translator/assembler for the different models (this seems overkill). Please, I really like to know your opinion. I'm getting confused about what data types can be exchanged between my components. Thank you. | |
| Aug 24, 2016 at 13:23 | comment | added | maple_shaft♦ | There is definitely less complexity and fewer logical layers in your specific instance, so I agree that for your application DTO's are probably overkill and a violation of DRY. What worries me about the OP's situation though is that he is using a legacy database, who knows what kind of schema changes could come in his future? Maybe they replace the database at some point or maybe another application is also using this schema and affecting his data model? More decoupling is always safer here. See my answer for my approach. | |
| Aug 24, 2016 at 13:08 | comment | added | Walfrat | @maple_shaft What i forgot to said is that my application is a REST Server, client side is an angularJS application. So i can have different objects if needed. | |
| Aug 24, 2016 at 13:03 | comment | added | maple_shaft♦ | I agree that DTO's can be a pain but it is even more a pain once you run into the limitation that your JPA entities and data model are dictating your UI data objects. You said it best though, judge the complexity of your application to make that determination. It is always a tradeoff. | |
| Aug 24, 2016 at 7:21 | history | answered | Walfrat | CC BY-SA 3.0 |