Generic User Management conflicts with Rich Domain Model

[thyrell]

Hi Martin,

[quote]
Great thanks! This was a very interesting read. Looks really smooth and well done. I understood nearly everything what's going on. Very good coding style, indeed.
[/qoute]

Thanks It's in a very rough form anyway. It also changed today The RegistrationTicket actually became UserEnrollment, a top level entity wich carries a immutable value called Ticket and a reference to the user. Anyway the functionality stayed the same

I would prefer a more descriptive name:

Yepp, good eye.

It turned out that the iBatis API only adds a minor amount of lines of code to the implementation. So I feel that there is no need to exclude these minor lines and define a common 'DAO' interface etc. I guess using a XML mapping file to specify the DAO related logic (SQL and mapping) works like a DAO itself. Just a quite different language than Java.

I don't know iBatis, just had a quick look. But will investigate when hibernates becomes to slow for me
I agree it feels a bit too much making the calls over the strategy-object there. But i did this to speed up testing when i test without a database (not yet but maybe later). And the one deferring call is not so costly i guess.

Okidok.. oh yes... writing the posts took a lot of time... not wasted time though.

cya
andi

[Martin Kersten]

Hi Andi,

I agree it feels a bit too much making the calls over the strategy-object there. But i did this to speed up testing when i test without a database (not yet but maybe later). And the one deferring call is not so costly i guess.

I don't know what exactly you mean by referring to costs. If it is about performance, I guess we can just agree that this stands on dont-care ground. But the real cost comes for just another interface and just another implementation (an therefore just another test). Also it would be nice to see how this general purpose persistence strategy behaves when it comes to losing the advantage of Hibernate and for every kind of object there needs to be a special persistance handling (manually select the table and map this object towards the table layout).

not yet but maybe later

I guess thinking ahead is a bit dangerous in terms of TDD. But we have enough experience to justify taking bigger steps - well hopefully at least. 8)


Cheers,

Martin (Kersten)

[thyrell]

I don't know what exactly you mean by referring to costs.

Yep, meant performance.

Also it would be nice to see how this general purpose persistence strategy behaves when it comes to losing the advantage of Hibernate and for every kind of object there needs to be a special persistance handling (manually select the table and map this object towards the table layout).

Well, i think it makes only sense if the implementation can use the specification (criteria) api. this would require to write your own criteria api. However i don't think it satisfies the work unless you really need to switch persistence frameworks frequently or you are a no-compromises-super-clean-strict-OO-guy.

I guess thinking ahead is a bit dangerous in terms of TDD. But we have enough experience to justify taking bigger steps - well hopefully at least.

Hehe, hope so too. But it does no harm, i could just remove the strategy object and doing it directly in the method. Also i find it hard not thinking ahead... constantly trying though

l8er
andi

[Martin Kersten]

I don't know iBatis, just had a quick look. But will investigate when hibernates becomes to slow for me Wink

Well I still use iBatis but I currently familiarize with the inline SQL abilities Hibernate 3 provides. I read an article on server side (was about August 2004) in which Garvin shows a way to use Hibernate with custom SQL (without any generated SQL at all). Since the possibilities envolved even further in Hibernate 3, I guess I will move the iBatis code to Hibernate and see how it turns out.

The code control in terms of SQL did really improved in Hibernate 3. Hopefully they write a new Version of 'Hibernate in Action' soon. There is so much to learn, but I guess they are waiting for the annotation going final (just guessing here, I have a sip of information ;-)).

But anyway, you should sniff into iBatis for sure. It only takes two or three days of learning and I guess it provides usefull knowledge beyond iBatis.


Cheers,

Martin (Kersten)

[thyrell]

Well I still use iBatis but I currently familiarize with the inline SQL abilities Hibernate 3 provides. I read an article on server side (was about August 2004) in which Garvin shows a way to use Hibernate with custom SQL (without any generated SQL at all). Since the possibilities envolved even further in Hibernate 3, I guess I will move the iBatis code to Hibernate and see how it turns out.

Yeah, i read about that and saw some examples too. I did not require this feature yet but maybe will be when optimizing performance. Hibernate3 is really nice - though i did not really check out others. I looked at Cayenne first, which i liked except for it's lack of transparence (you have to extend base classes for persistence and the like). Had a nice GUI tool though. That's what i dislike with hibernate. Yeah, there are all the Eclipse plugins - but i use IntelliJ which is lightyears ahead of Eclipse (IDE wise, Eclipse is a good platform of course, while Idea is "just" a IDE).

I'll have a look at iBatis when i have the time, but I'll stay with Hibernate until there is a concrete need to switch to somehting else.

l8er,
-andi

[Martin Kersten]

but i use IntelliJ which is lightyears ahead of Eclipse

Uhm. Wanna fight?

Well I guess, if Hibernate's annotation service goes final, I won't need mapping files except in rare situation. I am not a friend of additional xml-mapping files (XDoclet is neat but wasn't fully supporting the mapping features).

I never saw any reason to use a GUI for the Hibernate stuff also. What exactly tools are you referring to?

I looked at Cayenne first, which i liked except for it's lack of transparence

Well Cayenne I have never noticed. Just quick read the user guide... . Looks very neat. Are there any scenarios, where you would use Cayenne rather than Hibernate (or a JDO solution)?


Cheers,

Martin (Kersten)

[thyrell]

Uhm. Wanna fight?

It meant no offense. I'm not saying E is bad. In fact i'm using it at work. But privately I like Idea more (because of it's better speed on my slow machine and the real cool refactoring support). Anyway, no flame wars please :oops:

I am not a friend of additional xml-mapping files (XDoclet is neat but wasn't fully supporting the mapping features).

I'm not a friend of XDoclet though. Gets my brain too fuzzy. I'd like it in XML Mappings to have it cleanly seperated. So a visual tool for my mappings would be quite nice, but no must.

Well Cayenne I have never noticed. Just quick read the user guide... . Looks very neat. Are there any scenarios, where you would use Cayenne rather than Hibernate (or a JDO solution)?

Cayenne has a very cool graphical tool. You create your entire domain model with the visual tool and it generates classes from it. It also can import existing database schemas and generate classes from it and the like.
I would use Cayenne if the database would be there already and/or the domain model is basically mirroring the database model and you need a working thing as fast as possible. Though, I did not use it extensively, I played around with it only.

-andi

PS: For all that wonder, here's the link: http://www.objectstyle.org/cayenne/

[Martin Kersten]

It meant no offense.

I know, thats why I placed the smiley there. ;-)

I'm not a friend of XDoclet though. Gets my brain too fuzzy.

Well this depends. I liked using XDoclet back in the old days (year ago). But using mappings currently is also a nice idea. But that isn't much of a problem. The problem is the seperated file, I guess. Having two files to look at isn't that preferable. I don't know if the annotations will feel right all the time but what I saw was quite good.

But in the end, we just have to wait for a final version to be sure, I guess.

Cayenne has a very cool graphical tool. You create your entire domain model with the visual tool and it generates classes from it. It also can import existing database schemas and generate classes from it and the like.

That's good. I will write me a note about this.


Cheers,

Martin (Kersten)

[Martin Kersten]

Hi tyhrell,

I got my copy of 'JaverServer Pages in Action' today and they have a nice chapter 12 in it. You might want to grab yourself a copy and check this one one out. They have the following layers:

UI Layer
Application Layer
Business Layer
Integration Layer

at Page 474 there is an interesting thing also going on. Beside having a domain model, which I don't like instantly - something looks strange but yet I don't know why - they used IProjectCoordinator / IUserCoordinator instead of DAO or Repository. It's called Coordinator because it coordinates the access of the data source and the synchronization with it.

At page 476 it reads 'IProjectCoordinator is responsible for managing Project objects. It has basic database operations like add, remove, removeAll (basic?) and get.' This is usally what we came along with. DAO, Repository, Manager, Coordinator different names for similar things. I don't know if coordinator fits the picture that nicely. I didn't found a nice definition for it up to now, anyways.

Each layer is explained the following way on page 458 in the middle: "In addition to the UI layer, there is still an application layer, which consists of backing beans and other objects that interoperate with JSF. However the application layer doesn't know much about the business, or the data store. Instead, it counts on the business layer to deal with those things. The business layer doesn't know much about the application layer, but it does know a lot about the business. As a matter of fact, it has objects that model the business (called model or business objects), so in the case of ProjectTrack (Note: sample app), it includes User and Project objects. The business layer can be implemented using plain old Java Objects (POJOs), Enterpise JavaBeans (EJB), or webservices."

I am not about to agree with all of this but it is another try to get some clearness in the picture of layering... .

By the way: Does anybody know a good comparism of different layering approaches with a pro/contra discussion on each?


Cheers,

Martin (Kersten)