Креш - тест : багатошарова система для великої фінансової організації

Костянтин пише:

- Припустимо, ми розробляємо багатошарову систему для великої фінансової організації. Чи нормально мати персістенс моделі довжиною в сотні рядків коду з десятками властивостей? Зазвичай я відповів би - ні, не нормально, але тут самі специфікації містять описи таких величезних моделей (маса показників, коефіцієнтів, дат і всього іншого). Більш того, в'ю моделі теж, як на мене, перевантажені: безліч властивостей. Але це вимога замовника! Т. е., з глузду з'їхати, але кінцевий користувач, по ідеї, обожнює таблиці з сотень рядків і десятків стовпців!

Ось звідси і моє питання: це нормально для будь-який предметної області або це специфіка конкретної предметної області, для якої розробляється ПЗ, або це взагалі ненормально і що тоді з цим робити?

Привіт Костянтин.

Запросто, але це буде тільки моя думка. Та й питання дуже абстрактний. У реальному діалозі, я б обмежився простим «Так, так буває» і послухав би далі :) Але, так як це листування, дивіться нижче.

Наскільки мені відомо, жодна специфікація persistence layer не обмежує складність об'єктів. Так то єдине обмеження, яким слід керуватися в даному випадку - це фізичні обмеження використовуваної RDBMS (наприклад, PostgreSQL підтримує «всього» 4096 колонок в одній таблиці). Так що з точки зору дизайну, моделі з десятками і сотнями властивостей - це нормально.

Що стосується другої частини Вашого питання - будь-яка задача специфічна для предметної області. Будь. Саме тому не існує строгих специфікацій і гарантовано працюють правил створення persistence layer, або SOA, або чого б то не було. Ймовірно у Вашому випадку необхідно зберігати саме такий обсяг інформації саме в такій формі. Це, між іншим, не означає, що замовник обожнює непомірні таблиці, які дуже складно читати. Рівень представлення може дуже сильно відрізнятися від рівня persistence. Це, перш за все, означає, що замовник хоче зберігати всю цю інформацію в одному місці, доступно для редагування, і просто для резервного копіювання.

Ще один момент, як би дивно це не звучало, але з точки зору продуктивності, одна, нехай навіть дуже велика таблиця, краще (за інших рівних умов) двох десятків маленьких, пов'язаних один з одним безліччю зв'язків. У дуже рідкісних випадках, це не так. Інша справа, що підтримувати такі сутності дійсно складно.

І останнє, що можна з цим зробити. Не знаючи предметної області, Ваших відносин із замовником, ступеня Вашого впливу на прийняття рішень, ступенів Вашої свободи у зміні архітектури, коду та дизайну проекту, можу дати тільки загальні поради. Також, я не знаю мови і платформи, на якій Ви працюєте, тому рекомендації будуть спиратися на Java + JPA.

  1. Спробуйте проаналізувати структуру сутностей. Чи дійсно вони настільки монолітні і неподільні, наскільки це реалізовано. Чи всі ці десятки і сотні полів потрібні кожен раз, коли відбувається вибірка сутності. Якщо це не так (зрозуміло, тут буде складна розмова з замовником) то
    1. «зайві» атрибути має сенс розділити на логічні групи
    2. винести кожну з груп в окрему сутність, пов'язану з основною і поміченої fetch = FetchType.LAZY.
    3. таким чином, Ви зможете суттєво знизити навантаження на пам'ять і на RDBMS, не втративши при цьому даних, зв'язків і суттєво спростивши собі життя.
  2. Якщо ж сутності дійсно монолітні і неподільні, то логічно згрупувати поля все одно варто. Але замість зв'язкових сутностей можна використовувати @ Embeeded об'єкти. Цей термін добре знайомий людям, які працюють з Hibernate, суть такого рефакторинга полягає в тому, що велика таблиця з RDBMS представляється набором об'єктів рівня ORM. Фізично ми будемо мати єдину і неподільну таблицю з величезною кількістю полів, логічно - ієрархію об'єктів, заповнених даними з цієї таблиці.

З якихось загальних, не специфічних дій, які можна тут зробити - це, мабуть, два найбільш ефективних варіанта. Будь-який інший «тюнінг» потребує більш глибоких знань системи, її призначення, варіантів використання і тому подібного.

Резюмуючи, можу сказати, що описана ситуація нормальна. Реалізація може бути зроблена не найоптимальнішим чином, можливо, її можна поліпшити і зробити більш читабельною. Але якщо бізнес-завдання вирішене, то це саме те, навіщо взагалі розробляється ПО. Більш того, RDBMS підтримує велику кількість рядків і стовпців саме тому, що деякі завдання вимагають саме такої організації даних. Так що все, що можна зробити для поліпшення моделі - розділити її логічно і, якщо це необхідно і прийнятно, фізично. Наскільки сильно, зараз сказати не можу.

Надсилайте свої запитання через форму - http://dou.wufoo.com/forms/nnnnn-/ . Відповіді - кожен понеділок.

Опубліковано: 15/10/12 @ 08:15
Розділ Різне

Рекомендуємо:

Профіт Шоу з Вікторією Тігіпко , TA Venture , IDCEE
Показуємо твіти в WordPress блозі ( частина 2)
В рамках безпеки
Зроби сам
Публічний саппорт . Питання для Yuplay/1C/SoftClub