How to use DAO effectively in my MMO server

Question

I am working on a small multi player game for my final year project and currently working on the server. It's a Tank Battle game and have two main entities which I will use on the server side which are

Player (Player details like username, password, currentTank, statistics)

Tank (Details of a tank like velocity, rotationVelocity, Turret)

Turret(Details of turret like rotation velocity, fireRate, etc)

Statistics(stats like totalKills, total deaths, total shots etc)

I have recently read about DAO and how they separate out the database concerns and thought to use it in my project because my project does have good amount of data to persist and also due to the fact that I want to learn this technique.

After reading about DAO I realised there will be need to map the DTO to Domain Objects for business logic. As I am going to have quite a bit of logic on these object as well methods which are not really needed on DTO's.

So for example I map :

PlayerDTO -> PlayerObject

Whenever there is a request from player to move his tank, I queue the direction in a queue contained in player's tank. (This shows the need for having Domain Object as I don't need movement queue on the database but I need it on the tank objects to queue movements)

Now let's say in my MovementService of my server, I loop through the PlayerObject list (the logged in players) and update player's tank position in by calling the player.moveTank() which will update his positions according to the movement queued in the movement queue inside the TankObject contained in PlayerObject. I understand it till this point what I need to do.

Now my question is how will I save PlayerObject back to Database? Do I need to map it back to PlayerDTO? What is the most effective way to do it?

For now I have thought that when the player logs out,In my LogoutService I will use the PlayerDAO service and get the PlayerDTO using PlayerObject ID and update the object details and save him back to the database but I feel that I will be making extra database calls just to get the object (An extra select call) and to save it back rather than just updating the object using update query.

I also feel that just for updating let's say his position on the database I will have to use a query which will overwrite everything. Is there any better way of doing it or I am doing it right?

Note: I won't be using any ORM in my project.

P.S. I searched a lot but couldn't find any similar question. I know I haven't put any code and it's a long question but if anything is not clear let me know.

Answer 1

I wouldn't use the PlayerObject ID anywhere in this. I wouldn't "PlayerDTO using PlayerObject ID".

The player object ID should be irrelevant to you. Of course the DAO and especially the ORM (library or your own custom code) need it and use it, but the domain object shouldn't care about it. It only carries it around for the DAO's use. If I had my way, it wouldn't even be available from the domain object except perhaps through reflection or a DAO specific interface the domain object has to support in order to be persistable.

I am not up on the current thinking on this (haven't done a lot of database work lately), but in my mind DTO's (data transfer objects) only serve the purpose of limiting (or deriving) what gets transfered to and from a database. They are most useful when using an ORM because it allows the ORM to remain fully generic by working on - usually behaviorless - DTO classes. In essence the DTO serves as the map between the domain object and the information stored in the database.

So in your case, I would just hand a player domain object to the player dao service. The dao service would then either construct a player dto itself by inquiring the player domain object it received, or would ask the player domain object to provide a player dto instance, and then hand the player dto instance to the code that builds the queries and executes them against a database. That could be an ORM or your own code.

Whether the dao service constructs the dto, or the domain object does, is a trade off. I prefer the dao service to construct the player dto to be used by the database access code (custom or ORM). The reason is that the domain object should be unconcerned about any persistence - it should be able to assume that it will always be around. The dao service is the natural place for all persistence logic: where to store anything (db, file, registry), what needs to be stored (mapping of domain to dto) and how it needs to be stored (mapping of dto to tables and fields, xml structures or whatever) and what translations need to be done (for example translating an enumeration into the values for a character field in a table).

Answer 2

Instead of mapping the two, you could have the PlayerObject constructed around a PlayerDTO, and just keep the player info there. When it's time to save, ask it back from the Object.

AFAIK this would work also with ORMs, and one like Hibernate would worry about partial updates (efficiency considerations apart). Another path could be to remember "manually" (say in the object) if only the position has changed, and in that case use a particular DAO method that takes only the position from the DTO. But if you're saving just at the logout, overwrite everything.