views:

97

answers:

6

Hi!

I have what seems to be a simple employee time request web application I have to make (C#, Silverlight or ASP.NET). An employee can request vacation time, sick time, maternity leave, comp time, etc (there are probably about 10 different types of leave and could be more in the future) and their manager has to approve each request.

It really turns into a mess with all of the anomolies and such that I must anticipate. People in different roles get different amounts of vacation time, for example. Some people have vacation time accrued, and others get it all up from at the start of the fiscal year (September 1st). Employees have a bank they can keep of sick time and vacation time, but the size of these banks is limited and varies according to the employee role. At any point in time I need to be able to see how much an employee has left and how much is available to them. The biggest anomoly I believe, is that an employee can change roles (ie switch to a manager at any particular time and therefore start getting more vacation from that point forward).

It's quite a complicated problem. My question was this:

How should I design this? What is a good design pattern to use for this where I can be very flexible in the future?

Thanks!

+1  A: 

Politically, I would avoid the whole issue. You have to work with these people, and your app screwing up their vacation could get you maimed.

Anyhow, I would argue that tracking the accrual of vacation is really beyond your scope here, unless this is supposed to be a payroll and benefits tracking app. Rather, I'd let an appropriate party enter how much vacation an employee has at a given time and forward requests to managers and leave it at that.

Wyatt Barnett
I don't think it's beyond the scope if it's *part* of the scope. But I think the suggestion should first be (a) if there is an accrual system already in place (b) is there a way to interface with it.
Anthony Pegram
good point about the 'being maimed' part :). And yes this will also be for payrolls benefit to see who not to pay hours for (if they use too much time)
Rob
Someone has to write the software, why be afraid of talking to people? It's part of the job. Tracking vacation time accrual isn't too terribly complex. Just takes lots of business rules ;)
jlafay
Oh, I'd do it in a second if I were a hired gun. But I wouldn't touch HR/payroll/benes for people I work WITH. Big difference.
Wyatt Barnett
A: 

Given the complexity, it sounds like you need to design the time accrual process around a rules system. You need to define the rules that determine how vacation is accrued and apply them to each type of employee. Every rule that affects how vacation is earned must be implemented and applied as appropriate.

Try to design the rules in an object-oriented fashion: some rules may apply generally, others more specific.

You will need the ability to audit vacation time. When users are granted permission to use vacation time, use a ledger system to "withdraw" time earned. Grant time using the rules system on a regular (daily) basis, also using the ledger system.

Dave Swersky
A: 

A starting design pattern will be MVC, so probably make use of ASP.NET MVC as its built in ;)

This is so you can have your view code, separated from your more complex business rules you have for different employees.

The strategy design pattern will come in for calculating their time left, so you can encapsulate the code for working out how many days they have left based on if they are based from 1st September, or some other date.

JonWillis
Thanks for that, I'll look into the strategy pattern.
Rob
Strategy is a really basic design pattern. If your not familar with design patterns then read Head First Design Patterns. Also give Eric Evans Domain Driven Design a read if you have chance.
JonWillis
A: 

If possible, don't track the hours at all:
Just maintain an org chart and list of time off types and pass along requests to the requestor's supervisor

If you must track available hours:
It sounds like a couple (possibly large) lookup tables, in addition to the items above.

A schema like the below seems appropriate

(1) Employee  --> (1) Position --> (1/*) TimeOffAllowances 
              --> (1/*) AvailableTimeOff

In this design, you would either have a row in TimeOffAllowances/AvailableTimeOff with each column being for a type of allowance, or one row for each type. So relationships are either one-to-many or one-to-one. (the (1/*) in the above).

Then of course you will need an interface to enter all this data....

BioBuckyBall
A: 

Taking the "what design pattern will work" approach is never really a good way to solve a problem. The need which you described is really "how do I build an enterprise vacation management system". Design patterns do not solve this type of problem, design patterns are smaller scale. Enterprise systems usually use a number of different design patterns all through out the entire system. Design patterns are really just blue prints for an effective way to structure your code. Take a look at wikipedia for a more indepth view into what types of problems design patterns solve.

The short answer: None, there is no design pattern for this.

I think you need to sit down and start documenting how the system will work, all the features (no matter how big or how small), all the rules for how vacation time can be accrued and booked before you start thinking about code. You have a long way to go before you start coding.

Bob
A: 

I would take a look more at something like Domain Driven Design to describe the domain you are working with. Start by looking at the nouns you are using to describe the domain:

  • Employee
  • Manager
  • Role
  • Vacation Time
  • Sick Time
  • Maternity Leave
  • Request

These nouns are starting to define the models that you can define within the business domain. I would then take a look at the verbs that are associated with each noun:

  • An Employee can Request time off
  • A Manager can Approve a Request

These verbs are now defining your actions. You have the domain but you also need the front end, I would wrap the domain inside a service layer even if the service is not hosted anywhere and use a Repository pattern to isolate your data access layer.

As an side, take a look at what the Command Query Responsibility Separation (CQRS) to define the interaction between your user interface and your domain.

Ian Johnson