Data Access Layer - Using sessions to CRUD data.

Question

Hi,

I have a DAL to CRUD product data.

For example:

Order someOrder = new Order();
someOrder.Description = "Test";

someOrder.Save();
someOrder.Remove();

I need to design the DAL so that only users who have a lock on an Order type object can carry out CRUD operations.

My idea is to pass the session to the CRUD methods. Once I pass the session, the method will check whether that user has a lock on that specific object, and if yes, it will carry proceed with executing that method.

For example:

someOrder.Save(sessionThatContainsLockInformation);

// Pseudo-code
public void Save(Session session)
{

   1. Get user GUID from the session.
   2. Get lock details from the session.
   3. Check that the provided user has a lock.
   4. On success, proceed with saving the order.

}

I'm concerned with the fact that I'm using Sessions in the data access layer. My intuition tells me that I shouldn't be doing this. My goal is to write as little code as possible to promote the re-usability of code, but I seem to be stuck with the same ideas.

Can somebody please advise me on whether this is a sensible approach, or whether it has some fundamental disadvantages or maintenance overheads?

Any alternative solutions are welcome. I'm not interested in the code, just some ideas please.

Thank you

Answer 1

Hi,

This is just a couple of ideas, depending on persistence api of your choice. I believe Hibernate offers some "optimistic/pessimistic locking" mechanisms. I do not know the exact details of how these work but you should be able to find something on the hibernate homepage (in case you want to use hibernate). http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/transactions.html#transactions-locking

A simple (perhaps too simple, depends on the situation at hand...) DIY approach might be to have a simple timestampChanged row. At time of writing to DB, you will have to check whether the timestamp you want to save is the same as the last timestamp in the DB. But as I said, not all applications are suitable for this...

Hope this helps, Jan

Answer 2

Hi,

Thank you for your reply. My CRUD methods work and I don't have any issues there.

My concern is that I will have a lot of methods with very similar signatures and logic inside. For example I have the following classes:

Order Item Customer

Each one of those classes has the following methods: .Save() .Remove()

Inside of each method I have to check whether the user who is trying to run the method has rights to do so (has a lock on that object). In order to do so I have to pass user details and lock details into the methods, so I will end up with the following:

Public void Save(UserAndLockDetails details) {

}

Now image I have 50 classes instead of 3, which means there are 100 methods (Save(), Remove()) that I will have to update when the requirements change. I see this as a maintenance overhead, but I can't think of any alternative solutions.

Hope this makes sense.

Thank you

Answer 3

Hi,

Ok, thanks for your clarification, I think I understand your concerns now more clearly.

I faced a similar issue some time ago. My solution was a common superclass (in your classes it would be a superclass for Order, Item, Customer) with all parameters that are the same (timestamp changed, who did the change etc). I then created a utility class where all the checks you mention were taken care of. So this "maintenance" logic is implemented in one place only.

I am not saying this is the best way to do it, it's just something that worked for me...

Hope this helps, Jan