Using setter for work with database

Question

In project I have the class - model class (call this class - modelClass).

And I have a class (call this class - dbClass) which provide some methods for work with database (db - Advantage database architecture). This class provide static methods for work with database. I know that I can use some ORM(like EF), repository pattern, but in this project the main idea for work with database this is static class with static methods.

In modelClass I have thi field - "Status" (string type).

My use-case is update record in database when I set the filed "Status".

You can see my solution below:

public class modelClass{
    //here some fileds
    public string Status { get; set; }
    //here some fileds
}

public class dbClass{
    //here some fileds and method for work with database
    public static void update(modelClass mClass){
        //here update the record in database
    }
}

using

....
modelClass.Status = "status";
dbClass.update(modelClass);
....

I came up with another solution.

The idea of my decision is to use keyword "set".

Let me explain my idea - when I set the field in modelClass I want to set field and update record in database.

For example:

public class modelClass{
    //here some fileds
    private string Status { get; set; }

    //create public setter
    public string setStatus{
        get { return Status; }
        set
        {
            Status = value;
            dbClass.update(this);
        }
    }

    //here some fileds
}

using

modelClass.setStatus= "status";

The main questions is:

Is it good practice work with database by setter?
Why I should/shouldn't use this idea?
Please explain me main pros and cons of my idea

[SOLID principles](http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod) to your help. You're increasing coupling, thus some problems might arise. Questions: what if the DB interface changes? How do you test your class without a database? What if you need transactions that update multiple fields at once? — Dmitry Ledentsov, Feb 05 '15 at 10:29
I'm afraid this is too broad / opinion-based. See [Why should a C# property getter not read from a DB?](http://stackoverflow.com/questions/6682902/why-should-a-c-sharp-property-getter-not-read-from-a-db), [Should Properties have side effects](http://programmers.stackexchange.com/questions/82377/should-properties-have-side-effects) and so on. — CodeCaster, Feb 05 '15 at 10:30
@DmitryLedentsov , thank you for your answer. To be honest, I do not know how my decision I will be able to test this class, if there are changes to the database. Thank you for leading questions. I understood that my solution is bad :) — netwer, Feb 05 '15 at 10:36

score 2 · Accepted Answer · answered Feb 05 '15 at 10:51

So you are trying to distinguish between the classes that map onto the database in some way and the classes that are used by your business logic. That, I think, is a good idea. You are thinking of elements you'll also find in domain driven design, where the domain is 'persistence ignorant', i.e. doesn't know how, where or in what form it's being persisted.

However, I think there are more elegant ways of implementing it. By 'wrapping' the dbclass inside of your model class, you create a dependency form your model onto your database and that's exactly the thing you are trying to avoid.

What I've seen being used are model classes, and IRepositories for these model classses. The implementation of the repository is the one that knows about the persistence medium. Could by EF against SQL server, could be something Azure.

In case of an update, this repo will hydrate the dbclass from the database and then update the properties from the provided modelclass ( as you call them ). You can use AutoMapper for instance for taking care of this mapping. In case all your properties have the same name and type - it's just a one-liner:

OrderDto dto = Mapper.Map<OrderDto>(order);

oh, you give me the light on my idea :) ok, thank you for your answer. I will think about your idea. — netwer, Feb 05 '15 at 11:01

score 1 · Answer 2 · answered Feb 05 '15 at 10:39

No, it's not good practice.

For two reasons:

It'll sync with the database over-frequently.
Manually creating setter for each column in database is inconvenient.

Usually an ORM implementation has a way to traverse all the attributes, for example, using reflection.

Also it'll have a 'save' method so that you can flush the value in one call to the database after finishing assigning the fields.

Using setter for work with database

2 Answers2