سؤال

أردت أن أعرف ما يعتبره المجتمع "أفضل الممارسات" فيما يتعلق بإزالة التسلسل الهرمي للفئة مع الربيع JDBC.

ليس لدينا القدرة على استخدام أداة orm كاملة كاملة، ومع ذلك نحن نستخدم الربيع JDBC لتخفيف بعض الطبيعة المملة JDBC. فئة واحدة نستفيدها بانتظام للغاية هي الفاصوليا Hyrowmapper من أجل سهولة الاستخدام والقدرة على الوصول إلى ملكية فاصوليا غير حساسة من مجموعة النتائج لدينا.

لدي تسلسل هرمي فئة أن جميع الخرائط تعود إلى جدول واحد (اتخاذ نهج جدول لكل هاير للتسلسل الهرمي للفئة الصغيرة). على هذا النحو، يحتوي الجدول على عمود ClassID الذي يمكن استخدامه لتحديد الفئة التي يجب إنشاء مثيل لها بالفعل. السابق. 1 = المدير، 2 = الموظف، 3 = المقاول. كل هذه هي "أشخاص" ولكن كل فرعية من شخص لديه سمات قليلة فريدة من نوعها لفصلها.

فكرتي الأولية هي إنشاء فئة فرعية من beanpropertyrowmapper ومحاولة حقن هذا المنطق ليقول "إذا كان العمود a = 1 ثم إنشاء مثيل، ثم قم بإرساء الملزم الخاص بك".

هل هذا يبدو وكأنه نهج معقول؟ هل هناك أي اقتراحات أخرى قد يكون لدى الأشخاص الذين عملوا من أجلك؟

لك الشكر مقدما على أجوبتك،

جاستن ن.

هل كانت مفيدة؟

المحلول

لا يبدو أن هناك مكانا في الفئة الفرعية حيث يمكنك إضافة خطاف لتبديل الفصل دون نسخ تطبيق Maprow () بالكامل. قد يكون أفضل نهجك هو إنشاء فئة ROWMAPPER المندوبون إلى الفاصوليا المناسبين.

علي سبيل المثال:

    final RowMapper managerMapper = new BeanPropertyRowMapper(Manager.class);
    final RowMapper employeeMapper = new BeanPropertyRowMapper(Employee.class);
    final RowMapper contractorMapper = new BeanPropertyRowMapper(Contractor.class);

    RowMapper rm = new RowMapper()
    {
        @Override
        public Object mapRow(ResultSet rs, int rowNum)
            throws SQLException
        {
            int employeeType = rs.getInt("type");
            switch (employeeType)
            {
                case 1:
                    return managerMapper.mapRow(rs, rowNum); 

                case 2:
                    return employeeMapper.mapRow(rs, rowNum);

                case 3:
                    return contractorMapper.mapRow(rs, rowNum);

                default:
                    break;

            }
        }
    };

نصائح أخرى

لست متأكدا من أنها "أفضل الممارسات"، لكنني أقترح النهج التالي (بدون استخدام خصائص الفول -> يجب أن تعمل بشكل أسرع).

عادة ما تعرف نوع الكائن الذي تتوقع استرداده. لذلك يمكنك تقديم Mapper الصف المقابلة عند تنفيذ SQL.

أعلن مخصص مجردة Generic Rowmapper وإنشاء مخطط الصف خاص لكل نوع من النوع، أي:

private static abstract class PersonRowMapper<T extends Person> implements RowMapper<T> {

 @Override
 public abstract T mapRow(ResultSet rs, int rowNum) throws SQLException;

 protected void mapBase(ResultSet rs, T person) throws SQLException {
  //base mapping here
 }
}


private static class EmployeeRowMapper extends PersonRowMapper<Employee> {

 @Override
 public Employee mapRow(ResultSet rs, int rowNum) throws SQLException {
  Employee e = new Employee();
  mapBase(rs, e);
  //set other specific employee props
 }
}

من خلال نهج آخر، يمكنك إعلان طريقة مجردة في مخطط قاعدة لدعائم محددة، أي

private static abstract class PersonRowMapper<T extends Person> implements RowMapper<T> {
 @Override
 public T mapRow(ResultSet rs, int rowNum) throws SQLException {
  T instance = getInstance();
  //set base props here
  fill(rs, instance);
 }

 //e.g. return new Employee()
 protected abstract T getInstance();
 //fill specific instance props
 protected abstract void fill(ResultSet rs, T instance) throws SQLException;
}
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top