Почему я должен абстрагировать свой слой данных?

Question

Принципы ООП мне было трудно понять, потому что по какой-то причине я никогда не мог применить их к веб-разработке.По мере того, как я разрабатывал все больше и больше проектов, я начал понимать, как некоторые части моего кода могут использовать определенные шаблоны проектирования, чтобы их было легче читать, повторно использовать и обслуживать, поэтому я начал использовать его все больше и больше.

ОдинЯ до сих пор не могу понять, почему я должен абстрагировать свой слой данных.По сути, если мне нужно распечатать список элементов, хранящихся в моей БД, в браузер, я делаю что-то вроде:

$sql = 'SELECT * FROM table WHERE type = "type1"';'
$result = mysql_query($sql);

while($row = mysql_fetch_assoc($result))
{
    echo '<li>'.$row['name'].'</li>';
}

Я читаю все эти How-Tos или статьи, проповедующие о величииЗОП но я не понимаю почему.Кажется, я не сохраняю какие-либо LoC и не вижу, как их можно было бы использовать повторно, потому что все функции, которые я вызываю выше, кажутся просто инкапсулированными в классе, но делают то же самое.Единственное преимущество, которое я вижу для PDO, - это готовые операторы.

Я не говорю, что абстракция данных - это плохо, я задаю эти вопросы, потому что пытаюсь правильно спроектировать свои текущие классы, и ониМне нужно подключиться к БД, поэтому я решил, что я сделаю это правильный способ.Может быть, я просто читаю плохие статьи на эту тему:)

Буду очень признателен за любые советы, ссылки или конкретные примеры из реальной жизни по этой теме!

Answer 1

Я НЕ php человек, но это более общий вопрос.может расти лучше.

Суть в том, чтобы справиться с CHANGE

Подумайте об этом, у вас есть небольшой сайт социальной сети.Подумайте о данных, которые вы будете хранить, детали профиля, фотографии, друзья, сообщения.Для каждого из них у вас будут страницы типа pictures.php?&uid=xxx.

Затем вы получите небольшой кусочек SQL с кодом mysql.Теперь подумайте, насколько легко / сложно было бы это изменить?Вы бы поменяли 5-10 страниц?Когда вы сделаете это, вы, вероятно, ошибетесь несколько раз, прежде чем тщательно его протестировать.

Теперь подумайте о Facebook.Подумайте, сколько будет страниц, как вы думаете, будет проще изменить строку SQL на каждой странице!?

Когда вы правильно абстрагируете доступ к данным:

1. Он в одном месте, его легче менять.
2. Поэтому его проще тестировать.
3. Его легче заменить.(Подумайте, что бы вы сделали, если бы вам пришлось переключиться на другую базу данных)

Надеюсь, это поможет

Answer 2

Представьте себе абстрагирование слоя данных как способ сэкономить время в будущем.

Используя ваш пример. Допустим, вы изменили имена таблиц. Вам нужно будет перейти к каждому файлу, где у вас есть SQL, используя эту таблицу, и отредактировать его. В лучшем случае это был вопрос поиска и замены N файлов. Вы могли бы сэкономить много времени и минимизировать ошибку, если бы вам нужно было отредактировать только один файл, файл, который имел все ваши методы sql.

То же самое относится к именам столбцов.

И это касается только случая, когда вы переименовываете материал. Также вполне возможно полностью изменить системы баз данных. Например, ваш SQL может быть несовместим с Sqlite и MySQL. Вам нужно будет еще раз отредактировать множество файлов.

Абстракция позволяет вам отделить одну часть от другой. В этом случае вы можете вносить изменения в часть базы данных, не затрагивая часть представления.

Для очень маленьких проектов это может быть больше проблем, чем оно того стоит. И даже тогда вы все равно должны это делать, по крайней мере, чтобы привыкнуть к этому.

Answer 3

Одним из других преимуществ абстрагирования слоя данных является меньшая зависимость от базовой базы данных.

С вашим методом, когда вы захотите использовать что-то еще, кроме mysql или изменения имен столбцов или php API, касающихся изменения mysql, вам придется переписать много кода.

Если вся часть доступа к базе данных была аккуратно абстрагирована, необходимые изменения будут минимальными и будут ограничены несколькими файлами вместо всего проекта.

Также намного проще повторно использовать код, касающийся внедрения SQL или других служебных функций, если код централизован в одном месте.

Наконец, модульное тестирование легче проводить, если все проходит через несколько классов, чем на каждой странице вашего проекта.

Например, в моем недавнем проекте (извините, обмен кодами невозможен), связанные с MySQL функции вызываются только в одном классе. Все от генерации запроса до создания объекта делается здесь. Поэтому мне очень важно перейти на другую базу данных или использовать этот класс где-то еще.

Answer 4

По моему мнению, доступ к данным является одним из наиболее важных аспектов, чтобы отделить / абстрагироваться от остальной части вашего кода.

Разделение различных «слоев» имеет несколько преимуществ.

1) Он аккуратно организует вашу кодовую базу. Если вам нужно внести изменение, вы сразу узнаете, где нужно внести изменение и где найти код. Это может не иметь большого значения, если вы работаете над проектом самостоятельно, но с большой командой преимущества могут быстро стать очевидными. Этот пункт на самом деле довольно тривиален, но я все равно добавил его. Настоящая причина - номер 2 ..

2) Вы должны попытаться отделить вещи, которые могут потребоваться изменить, независимо друг от друга. В вашем конкретном примере вполне возможно, что вы захотите изменить логику доступа к БД / данным, не влияя на пользовательский интерфейс. Или вы можете изменить пользовательский интерфейс, не влияя на доступ к данным. Я уверен, что вы можете увидеть, как это невозможно, если код смешан друг с другом.

Когда ваш уровень доступа к данным имеет четко определенный интерфейс, вы можете изменять его внутреннюю работу так, как вам хочется, и, пока он все еще придерживается интерфейса, вы можете быть почти уверены, что он не сломает ничего дальше. Очевидно, что это все еще нужно проверить с помощью тестирования.

3) Повторное использование. Написание кода доступа к данным может стать довольно повторяющимся. Это еще более повторяется, когда вам нужно переписать код доступа к данным для каждой страницы, которую вы пишете. Всякий раз, когда вы замечаете что-то повторяющееся в коде, должны звучать сигналы тревоги. Повторяемость, подвержена ошибкам и вызывает проблемы с обслуживанием.

Я уверен, что вы видите одинаковые запросы, появляющиеся на разных страницах? Эту проблему можно решить, поместив эти запросы ниже на уровне данных. Это помогает облегчить обслуживание; всякий раз, когда имя таблицы или столбца изменяется, вам нужно только исправить одно место в слое данных, которое ссылается на него, вместо того, чтобы проскальзывать через весь пользовательский интерфейс и потенциально что-то упустить.

4) Тестирование. Если вы хотите использовать автоматизированный инструмент для проведения модульного тестирования, вам нужно все красиво разделить. Как вы будете проверять свой код, чтобы выбрать все записи о клиентах, когда этот код разбросан по всему интерфейсу? Это намного проще, когда у вас есть особая функция SelectAllCustomers для объекта доступа к данным. Вы можете проверить это один раз здесь и быть уверенным, что он будет работать для каждой страницы, которая его использует.

Есть и другие причины, которые я позволю другим людям добавить. Главное, что нужно убрать, это то, что разделение слоев позволяет одному слою меняться, не позволяя изменениям распространяться на другие слои. Поскольку база данных и пользовательский интерфейс являются областями приложения / веб-сайта, которые наиболее часто меняются, очень полезно держать их отдельно и красиво отделенными от всего остального и друг от друга.

Answer 5

С моей точки зрения, чтобы напечатать только список элементов в таблице базы данных, ваш фрагмент более подходящий: быстрый, простой и понятный.

Я думаю немного большев других случаях абстракция может быть полезной, чтобы избежать повторений кода со всеми связанными преимуществами.

Рассмотрим простую CMS с авторами, статьями, тегами и таблицей перекрестных ссылок для статей и тегов.

ВВаша домашняя страница Ваш простой запрос станет более сложным.Вы будете присоединяться к статьям и пользователям, затем вы будете получать связанный тег для каждой статьи, присоединяясь к таблице тегов с перекрестной ссылкой и фильтруя по article_id.

Этот запрос будет повторяться с небольшими изменениями в профиле автора ив результатах поиска по тегам.

С помощью инструмента абстракции , подобного этому , вы можете определить свои отношения один раз и использовать более краткий синтаксис, такой как:

// Home page
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name');
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

Вы можетеуменьшите количество повторений оставшегося кода, инкапсулируя его в Модели и рефакторинг приведенного выше кода:

// Home page
$articles = Author::getArticles();
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = Author::getArticles()->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = Author::getArticles()
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

Существуют и другие веские причины абстрагироваться более или менее с его плюсами и минусами.Но, на мой взгляд, для большей части веб-проектов главное - это P