Discussion of the database interface.



  • Hello, distinguished professionals.
    I'm asking you a question for discussion. The issue concerns the interaction of the programme with the database.

    There you go. There's a lot of techniques to work with the OBD. Do you think the work set out below is good? If you don't, you'll have to comment on what's wrong.

    Suppose there is some OBD interface that fully assumes responsibility for the establishment and removal of connections and provides information from the base in different types in such a way (name it DBProvider😞

    1. Create a new facility DBProvider;
    2. To call for a data collection function;

    Let's say we have creatures.@Entityfor each table. Of course, in order to accomplish many tasks, there will be no cost to one object. It is necessary to create its own, multi-dimensional mixtures, and the data must be stored according to certain conditions of request. For example, there are two tables: staff and supervisors. Each staff member and supervisor have their standard data, and the staff member is also assigned to his supervisor (I hope the dependence is clear). We need to create an object. Подчиненные (i.e. subordinates to some superior, and data, allowed only FO). The object will be approximately:

    class Subordinates {
        privat String chiefName;
        privat String[] subordinateNames;
        //Геттеры и сеттеры
    }
    

    Of course, it will have to be initiated in a class that uses it (or elsewhere) by requesting OBD, converting, entering data into the object field...
    Well, if you're gonna make this class self-containing data from the base on the parameters to be transmitted to the designer or separately. For example:

    class Subordinates {
        privat String chiefName;
        privat String[] subordinateNames;
    
    public Subordinates(int chiefId, int minRate, int maxRate) {
        DBProvider dbp = new DBProvider();
        //извлечение из бд записей и
        //инициализация полей в соответствии с критериями поиска
    }
    //Геттеры и сеттеры
    

    }

    It's just that this class's object is entirely responsible for itself. The creation of such facilities will be limited to the transfer of search criteria. It is no longer necessary to create a layer in the programme where data will be extracted (e.g. DAO).
    If graphically expressed, it will be approximately as follows:

    alt text

    Here. ValueObject Use it. DBProvider to extract data, then makes all necessary calculations and changes with the data obtained. Ultimately, a ready-to-read facility with data (Value Objectwho already uses business logic. Don't forget that DBProvider fully encapsulates all OBD operations.

    If anyone has seen an article confirming or refuting the convenience of this scheme, please refer. If anyone disagrees or agrees with this arrangement, please write your opinion plus arguments. I'd love to accept the offer of a scheme that is much better than this.

    UPD1:
    A more detailed description of the principle of action. Method DBProvider We need to go. SQL- Request for data addition, removal or editing. I mean, in my example, a class designer. Subordinates I'll send a request, for example.

    //...
    chiefName = dbp.getString("Select имя from начальники where код=" + chiefId);
    subordinateNames = dbp.getObjects(/* Запрос на выборку данных одного столбца */).toArray();
    //...

    Well, that's an exemplary principle. Let's go. DBProvider may also initiate simple objects (bones or essence) and return the site ' s array with data. And the task of updating the database after the data in the facility were changed Subordinatesit's on its own.



  • Well, for starters, there's not much here, mostly starters.
    With regard to your scheme, there's a lot to be found and many used. Especially Oralists. She's got some problems:

    • Losing some flexibility in extracting data is harder to apply
    • When changing the data structure, do not forget to change classes
    • If data extraction is accompanied by new connections or frequent reconnections to the database, it must be taken into account that the resource may not be endless - brakes may begin at some point.

    If you're not embarrassed by these moments, you can use such a scheme without problems. The benefits of this approach, I think you know.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2