On 26.02.2010 12:46, Durchholz, Joachim wrote:
public String getTableName(String standardTableName) { if("logging_event".equals(standardTableName) { return standardTableName; } if("logging_event_property".equals(standardTableName) { return standardTableName; } if("logging_event_exception".equals(standardTableName) { return standardTableName; } throw new IllegalArgumentException(standardTableName + " is an unknown table name"); }How about enum TableName {EVENT, EVENT_PROPERTY, EVENT_EXCEPTION} public String getTableName(TableName tableName) { switch (tableName) { case EVENT: return "logging_event"; case EVENT_PROPERTY: return "logging_event_property"; case EVENT_EXCEPTION: return "logging_event_exception"; } } Using an enum has two advantages: - Compilers can (some will) complain if you forget a case in the switch - uses of TableName can be traced with cross-referencing tools The disadvantage is that you can't extend the list. However, if that kind of flexibility is needed, I'm not sure that a separate resolver class is a good solution. It would need to provide a table name for whatever the internal workings of DBAppender require, so the coupling would be too tight. (If logback can use generic classes, then DBAppender<DBNameResolver> would be optimal IMHO.)
Using enums is a good idea. Both implementations of DBAppender the one in logback-classic and the one in logback-access depend on distinct table structures, but a table structure is assumed nonetheless. The DBNameResolver only decouples the table/col names from that assumed structure.
Regards, Jo
_______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
