0

I have an application where a Job can have one pay strategy - per mile, per hour, salary, or allowing for any additional strategy in the future.

In the database I have a Jobs table, of course. I would anticipate I need a lookup table for the strategies.

However, when it comes to the objects/classes and the data that gets stored as part of a strategy, i am unsure how to proceed.

Theoretically I should have IPayStrategy, and a concrete class for each strategy.

But when it comes time to present a data entry form and a pay strategy is chosen, the next part needs to ask for values related to that strategy.

Each class could have a viewlet that would define how to present the data input fields, and that's fine with me (unless y'all have another way of thinking about it...), but when it comes to actually STORING that data, does this design then limit me to creating a brand new database table for each pay strategy that comes up now or in the future? As in, each of the pay strategies i've mentioned only requires a single value, but it's possible that another pay strategy could come along in the future that requires more complex data entry of some kind... so how do you tie a pay strategy to a job, and store the data?

In short, how does data storage work with the Strategy design pattern?

I have a feeling my disconnect here might be related to the Strategy pattern being for behavior alone(?), but this behavior necessarily has data tied to it...

I welcome your input!

Franc Amour
  • 301
  • 1
  • 11
  • Relational databases are for relational data. Data you wish to query against. If you're just storing application state, serialize your object graphs and dump it into an nvarchar(max). –  Nov 19 '15 at 19:36
  • I'd rather not serialize, though that was one thought, as i may in fact have to query against this data ("show me all annual salary jobs offering $28k or more") - such a query could have some real overhead. – Franc Amour Nov 19 '15 at 19:38
  • Well, relational databases don't work with polymorphic data. So you might have to find a compromise. Serializing to xml (or xaml) and saving it as XML will let you query the state of the data, which might help certain situations. –  Nov 19 '15 at 19:51
  • your comment led me to an additional search, and it seems i'm faced with the choices outlined here: http://stackoverflow.com/questions/45621/how-do-you-deal-with-polymorphism-in-a-database – Franc Amour Nov 19 '15 at 19:57
  • and this one as well: http://programmers.stackexchange.com/questions/264139/database-design-for-polymorphic-data – Franc Amour Nov 19 '15 at 20:02
  • I think I'm leaning towards a table called PayStrategies, and for each strategy, there would be tables like PayStrategySaleries, PayStrategyHourlies, PayStrategyPerMile; in my application I'm going to have classes for each of those three than all inherit from a base PayStrategy class. This kinda lines up with my development/framework, as i have a class file for each table anyway... and if I'm going to add a new pay strategy class, it makes sense that I'd add a table too... which doesn't force modification of any existing entities. – Franc Amour Nov 19 '15 at 20:08
  • I'd like to give you credit for your (FAST and VERY APPRECIATED!!) response, because by simply reminding me of the word polymorphism you led me on the right search path. How do i give credit? – Franc Amour Nov 19 '15 at 20:08
  • (to close out the solution i intend to use, i'm going to go with this option, since there won't ever be a great many pay strategies: http://www.martinfowler.com/eaaCatalog/classTableInheritance.html) – Franc Amour Nov 19 '15 at 20:36
  • No worries. Best way to credit is to add an answer below with enough details that someone else in your same predicament would find it helpful. –  Nov 19 '15 at 21:57

0 Answers0