Мені цікаво, які недоліки використовується у шаблоні ActiveRecord для доступу до даних та бізнес-об’єктів. Єдине, про що я можу придумати верхній частині голови, - це те, що він порушує Принцип єдиної відповідальності, але модель АР досить поширена, що ця причина сама по собі не здається «достатньо хорошою», щоб виправдати її використання (звичайно, моя подання може бути перекошеним, оскільки часто жоден з кодів, з якими я працюю, не відповідає жодному із принципів SOLID).
Особисто я не прихильник ActiveRecord (за винятком написання програми Ruby on Rails, де AR відчуває себе "природно"), тому що відчуває, що клас робить занадто багато, і доступ до даних не повинен бути відповідним самому класу справлятися. Я вважаю за краще використовувати сховища, які повертають бізнес-об’єкти. Більшість кодів, з якими я працюю, прагнуть використовувати варіацію ActiveRecord у вигляді (я не знаю, чому метод є булевим):
public class Foo
{
// properties...
public Foo(int fooID)
{
this.fooID = fooID;
}
public bool Load()
{
// DB stuff here...
// map DataReader to properties...
bool returnCode = false;
if (dr.HasRows)
returnCode = true;
return returnCode;
}
}
або іноді більш "традиційний" спосіб створення public static Foo FindFooByID(int fooID)методу для шукачів і чогось у порядку public void Save()збереження / оновлення.
Я розумію, що ActiveRecord, як правило, набагато простіший у застосуванні та використанні, але це здається занадто простим для складних додатків, і ви могли б мати більш надійну архітектуру, інкапсулювавши свою логіку доступу до даних у сховищі (не кажучи вже про те, що простіше заміняти стратегії доступу до даних, наприклад, можливо, ви використовуєте Stored Procs + DataSets і хочете перейти на LINQ або щось подібне)
Отже, які ще є недоліки цієї моделі, які слід враховувати, вирішуючи, чи найкращим кандидатом на роботу є ActiveRecord?