Implement a Save method for my object

Question

I\'m trying to improve my application\'s design, So instead of calling the DataAccess layer from the presentation layer. I\'ll try to implement a save method from my object

Answer 1

if you follow this pattern you will have the saving logic inside the object definition itself, so when you call from PL:

obj.SaveObject();

this will happen in the Object itself:

public void SaveObject()
{
  DAL.SaveObject(this);
}

and your DAL stays the same as you shown above.

it's a matter of design, I would not put the logic of saving inside the object but I would have a BusinessManager or an ObjectMapper to read from DAL and save to DAL.

in general is a good practice to have read or load and Save in the same place, BusinessObject or BusinessManager, but together so you find them easily and update both in a breeze if you add or change a field.

Answer 2

Passing the object itself to the data layer is usually a bit funky. Instead, I recommend that you have the object do the talking to the data layer, and let the data layer do its thing.

internal static class DataLayer {

    public static bool Update(int id, string label) {
        // Update your data tier
        return success; // bool whether it succeeded or not
    }
}

internal class BusinessObject {

    public int ID {
        get;
        private set;
    } 

    public string Label {
        get;
        set;
    } 

    public bool Save() {
        return DataLayer.Update(this.ID, this.Label); // return data layer success
    }
}

The reason you would do it this way, is because your data layer may not have a reference to your business object, and thus would have no idea what it is. You would not be able to pass the object itself. This is a usual scenerio because generally it is your business object assembly that references your data layer assembly.

If you have everything in the same assembly, than the above does not apply. Later on however, if you decide to refactor your data layer into its own module (which is often how it turns out, and is good design), passing the object will break because then it loses its reference to your business object.

Either way you do it, you should know that you will have to update both your object and your data layer if you add a new field or member. That's just a given when you add something new.

I may write a blog on some good design practices for this, but that is my recommendation.

Answer 3

You should avoid mixing the domain model with the persistence logic. The examples given above would make a tight coupling solution. In order to achieve the .SaveObject() you can make extension methods in the BL that would do the job.

BL.*

public static class ObjectPersistanceExtensions{

       public static SaveObejct<T>(this IBaseEntity obj){

            IObjectDal<T> _dal = AvailableSerices.Obtain<IObjectDal<T>>();
            _dal.AddObject(obj);
            _dal.Commit();
       }
}

So in this way you can still add functionaries to the domain objects without coupling the logic in the domain objects.