Refactoring Database Access in Marauroa: Difference between revisions
Content deleted Content added
imported>Hendrik Brummermann |
imported>Kymara |
||
| (69 intermediate revisions by 3 users not shown) | |||
Line 1:
== Requirements ==
Line 23:
=== Where did IDatabase / JDBCDatabase go? ===
It was replaced by smaller classes
=== What are those new ...DAO classes? How do they work? ===
These classes replace the old IDatabase / JDBCDatabase and do the database stuff. All of their methods have two signatures: One with
=== I have extended the JDBCDatabase class. How does this work with DAOs? ===
Line 35:
DAO classes should never be instantiated directly. Instead you should (and marauroa does) use the DAORegistry. This allows you to write a subclass of a DAO provided by marauroa and register it instead. If you are familiar with Spring, this is a similar concept. But without all the bulk of xml configuration files, parameter injection and interfaces with only one single implementation.
Imagine you want to subclass the CharacterDAO with your class
<source lang="java">
public class SomeGameCharacterDAO extends CharacterDAO {
...
</source>
You simply register it as
<source lang="java">
DAORegistry.get().register(CharacterDAO.class, new
Note: In the register call the first parameter is the parent clase you want to replace.▼
</source>
=== What are those database adapters for? ===
=== Why is there a method getLastInsertId? ===
Line 66 ⟶ 68:
=== What happened to Transaction, JDBCTransaction, Accessor, JDBCAccess? ===
They
=== What
They have been moved to marauroa.server.db
Line 79 ⟶ 81:
== Porting of JMaPacman ==
The following diff shows
<!--
Don't use syntax highlighting here because it does not work well with the diff characters and bold formation
<source lang="java">
-->
public class MaPacmanRPRuleProcessor implements IRPRuleProcessor
{
Line 162 ⟶ 167:
}
}
[[Category:Marauroa]]
| |||