Timesheet, CSLA and OOP

un7lg posted on Wednesday, July 11, 2007

This is my first project using CSLA as a framework. My learning curve is slower that I would like to see it and I need some help from CSLA community.

The project is a Project Cost Control application.

The timesheet is a main point of keying data into system.

As it is a construction industry, the timesheet is more complicated than a "regular" one.

Moreover, construction sites are located in a remote area and a dialup internet is only a choice.

So here we go:

TIMESHEET (It could be a few different types of timesheets - labour, expense)

WA - work authorization (usually only ONE WA per timesheet, but could be more)

WO - workorder ( under each WA it could be many of them)

RESOURCE - labour, equipment, material, expenses (we have to assign resources to every WO, and labour might be organized into teams to easily create timesheet on a daily basis)

TIMECODE - ( for every resource it can be many timecodes. For example, Labour - REG, OT, DT are always used, but many others (7-12 of them) used occasionally)

CODE UNIT - (with every TIMECODE has to be associated some units, such as hours, amount or qty of something.)

As a Document TIMESHEET has header of general information about project, timesheet itself ( #, Date,,,) and sub headers of information about WA ( WO, Cost Center, Desc).

All data created in TIMESHEET I want to save in one Details table with foreign keys to all other tables, including timesheet table.

What would be the best CSLA object structure to handle it?

As I mention, internet is not good, and I do not want to hit database every time if my objects required data.

Perhaps, I should keep connection open during the time a timesheet created.... but timekeepers can leave it open over night easily.

Thanks,

Pavel

hurcane replied on Wednesday, July 11, 2007

I think you have already figured out your object structure.

TimeSheet = EditableRoot, which contains a child list of work authorizations (because there could be more than 1, even there isn't usually more than 1)
WorkAuthorization = EditableChild, which contains a child list of work orders
WorkOrder = EditableChild, which contains a child list resources
Resource = EditableChild, which contains a list of time entries
TimeEntry = EditableChild, which has properties for time code and code unit

That's the easy part, although loading great-great-grandchild data (i.e. TimeEntry) will be fun to design.

The hard part will be designing for performance over a dialup line. There are no general guidelines for that beyond avoiding a "chatty" design and cache where possible.

un7lg replied on Thursday, July 12, 2007

hurcane:

The hard part will be designing for performance over a dialup line. There are no general guidelines for that beyond avoiding a "chatty" design and cache where possible.

I do not like it too and what I am thinking about is to install local MS SQL Express and replicate databases on some schedule.
It would give a better user experience, but I have to alarm remote timekeeper database on some changes made in a main database in the main office
Theoretically it's possible and could be the best solution for me.
In practice, in the very beginning of the project there are a lot entries done, such as Employees, new codes....but then it just a few master table changes would be made, except Employees are still hired and fired.
Or just cache all master tables on every connection as they are not big, but only Labour table is concern that could be up to 750 names for a project.
Any opinion ?.

hurcane:

That's the easy part, although loading great-great-grandchild data (i.e. TimeEntry) will be fun to design.

As I mention it would be just one table and I have to save only foreign keys mostly. I have to test it any way with CSLA .

hurcane replied on Thursday, July 12, 2007

How are you going to store 5 levels of 1-many relationships in a single table? If I understand your design correctly, a timesheet can have multiple work authorizations on it, each work authorization could have multiple work orders, each work order can have multiple resources, and each resource can have multiple time entries..

I'd have five tables for this data entry scenario. Or maybe I am misunderstanding your use case.

I think replication between SQL Express at the client and SQL 2005 in the office is a good idea. Don't replicate any more data than you absolutely need when the client is disconnected.

Pavel replied on Sunday, January 10, 2010

I am back to this thread as the complexity of a timesheet is a good example of how difficult could be an OOP.

So, I need some advice how to deal with such a scenario:

-on timesheet I have up to 3 Workorders.
-Employee can be assigned to all of them the same time, or only to one.
-Paycodes(reg time, subsistence, meal....) assigned to Empolyee.

The problem I see here that if I have 12 Paycodes I have to create 12 Paycode objects to be added to PaycodeList.

So, simple calculation would give me:
12 Employee per Timesheet and 3 Workorders and 12 Paycodes per Employee-Workorder would give at maximum 432 PayCode objects to be created.

I see that if I would create PayCode object when user actually enters it into a Timesheet would be a slow as I have to do steps like:
-create a Paycode object
-assign Paycode to PaycodeList(if not there yet)
-assign PaycodeList to Employee
-assign Employee to EmployeeList (if not there yet)
-assign EmployeeList to Workorder (if not there yet)
-assign Workorder to WorkorderList (if not there yet)
-assign WorkorderList to Timesheet (if not there yet)

Probably, I am going to a wrong direction and there is a more elegant way to do it.

Thanks for any idea,

Pavel

ajj3085 replied on Monday, January 11, 2010

Keep in mind that you may have more than one object graph for timesheets (for example), if editing a timesheet can be done through different use cases. I think you're trying to jump into the class design too quickly. Step back, and solidify your use cases. Then design an object graph that supports each use case. Only then would you consider the object behaviors across use cases and determine which ones overlap, and simplify your model. But initially take it one use case at a time.