update DB from layered architecture: best approach?

Question

I'v e built a basic DAL which can retrieve data and a businesslayer with several objects using this DAL. Once I mapped the data into the business objects and done something with it, I also want to write the data back to the database. Some of the business objects have a lot of properties, so passing every value of a business object as parameter to a method of the corresponding dataservice is not a possibility.

Other ways I've been thinking of:

1. pass the business object to the the corresponding data service, there execute a SP with all the values as parameters. - sucks, because I have to pass a business object to the DAL (violating the separation) and probably end up with SPs with >50 parameters

2. create an empty (?) dataset within the business object, fill it with the values from the business object, pass that dataset to the data service and update the db via a dataadapter. I thought of creating an empty dataset with a "... WHERE 0"-SQL String. Would that be a good practice?

This is the first time I do something like this. The latter sounds better to me, but maybe there are other, better approaches? Or The first one is better for some reasons I don't know?

Thank you very much!

[edit:] I can't use LinQ2SQL, cuz I use C# Express (which only supports querying local DBs, while mine is a remote one)

Answer 1

why do you think that when passing a business object to the DAL you are violating the separation. maybe you should think on separating the bussines objects into another layer.

also you could try linq2SQL in that way you can forget about parameters and this will reduce the number of your SP's.

Answer 2

You haven't mentioned using LINQ. Is that because you're not using .NET 3.5 yet?

Also, you don't have to make your DAL that generic. The callers of your DAL aren't trying to update all properties of the business object, are they? They probably want to update parts of it, so you should present an API that does this. For instance, they might just want to add an address to a Contact object, or possibly even update a phone number. You need to have a tradeoff between doing what the caller is really trying to do, and the number of separate methods you'd need in order to do that.

Answer 3

Unless your Data Access Layer is very generic, how would passing a business object be bad?

I'm a fan of serializing the object and passing the XML to a stored proc, but I'll probably be in the minority.

Answer 4

Pass your object into your DAL. If your writting the DAL layer manually your DAL layer should know how to take an Entity and persist it to the DB, and how to return an Entity from the database. The DAL is about persistance of your entities to a non-volatile medium.

Answer 5

The DAL should be all about mapping between your business objects and the specific data representation. This is why the Repository pattern that works with the domain objects, allows you to switch to a different persistance implementation, that might not even be a database.

You are concerned about needing to pass too many parameters to the DAL's methods, and then mention an example where you only need to pass 2 or 3 values. If that is the case, passing it as the method's arguments is reasonable. If you are passing more values, one way you can achieve it is by defining an interface with the subset of values you want to save. This way you are specifying clearly the info that method will be handling.

Regardless of the above, don't make the methods too specific, as you would end up with lots of combinations which can make it harder to mantain.