Простая модель БД

Question

У меня нет большого опыта использования фреймворков или чего-либо еще, поэтому у меня мало опыта в использовании моделей (MVC). Я не заинтересован в использовании фреймворка на данный момент. Я работаю над веб-сайтом и пытаюсь смоделировать некоторые объекты, но не знаю точно, как мне следует проектировать класс.

Например, сейчас у меня есть класс с несколькими открытыми членами, к которым можно получить прямой доступ. Я начал создавать прототипы некоторых функций (выбрать, удалить, обновить), но я не уверен

1. Если эти функции должны быть статическими
2. Если эти функции должны принимать параметры или использовать членов класса вместо
3. Если эти функции должны существовать, как они существуют в настоящее время
4. Если вся концепция, к которой я иду, правильная вещь

Кажется, я не могу найти какие-либо намеки на создание классов модели.

Answer 1

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

Если MVC является для вас новой концепцией, то разработка через тестирование почти наверняка и чужда. Тем не менее, я впервые понял, что такое ООП, поэтому предлагаю вам попробовать. Написание нескольких простых модульных тестов сначала для ваших классов моделей поможет вам понять, как будут использоваться эти классы моделей. Вы будете работать с внешним API каждого из этих объектов (или групп объектов, если вы не являетесь приверженцем TDD), и это поможет в разработке внутренних компонентов. Для начала ознакомьтесь с PHPUnit , поскольку в документации также есть несколько замечательных примеров.

Я думаю, что подход TDD приведет вас к следующим выводам:

1. Вероятно, нет. Статические данные / методы обычно полезны только тогда, когда вам абсолютно необходима одна копия чего-либо. Я нахожу в веб-приложениях, что, за исключением, возможно, соединения с ресурсами, такого как БД, это редко встречается.
2. Это зависит от того, что делает функция. Имейте в виду, что использование локальных переменных подразумевает побочные эффекты или изменения в состоянии объекта. Если данные, с которыми вам нужно работать, не должны изменять состояние всего объекта, используйте параметр и верните значение. Также проще тестировать такие методы.
3. Опять же, написание тестов для этих функций, которые иллюстрируют, как вы будете использовать их в приложении, приведет вас к тому или иному выводу о том, нужны ли вам они или правильно ли они разработаны. Не бойтесь их менять.
4. Абсолютно. Как еще вы будете чувствовать себя комфортно с MVC, если вы не развернете свою собственную реализацию хотя бы один раз? На самом деле, вероятно, лучше понять концепции с реальным опытом, прежде чем переходить на более профессиональный подход. Таким образом, вы поймете, почему концепции и соглашения фреймворка такие, какие они есть.

Да, и отсутствие ясности в том, что такое класс модели, возможно, связано с тем, что именно часть вашего приложения наиболее адаптирована. Это ваша модель данных и логика предметной области, поэтому многие из них зависят от конкретного случая. Тем не менее, лучшим ресурсом, IMHO, является Мартин Фаулер, чья превосходная книга «Образцы архитектуры корпоративных приложений» подробно рассказывает о том, как и зачем проектировать определенный набор «модельных» классов с тем или иным шаблоном. Вот онлайн-библиотека - очевидно, книга более подробная.

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

Answer 2

Если вы используете фабричный класс, то все глаголы обычно являются методами экземпляра, а фабрика создается с помощью какого-то сеанса БД.

Если глаголы являются членами класса объекта, выбор, как правило, является статическим методом, тогда как обновление, как правило, является методом экземпляра, а удаление обычно определяется обоими способами (IE: delete(recordID) и entity.delete())

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

Answer 3

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

Несмотря на то, что объектно-реляционное отображение гораздо более распространено среди языков со строгой типизацией, таких как Java, уже есть инструменты для PHP (например, Doctrine ). Вы можете проверить это, если вам нужна OO-ориентированная модель, но имейте в виду, что OR-mapping имеет серьезные проблемы и может быть мало полезен в PHP (еще не пробовал сам на динамическом языке) .

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

Answer 4

«Правильный» способ абстрагирования доступа к данным с использованием объектно-ориентированных концепций - актуальная тема для многих людей. Иными словами, есть несколько способов сделать это, и не существует «одного правильного» способа.

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

Если вы начинаете новую кодовую базу и не работали с фреймворком или объектным уровнем, но знаете, что вам нужно ее создать, то лучший совет, который я могу дать, - это желание создать его позже и реорганизовать код подойти, когда это произойдет. Да, это, вероятно, будет означать, что ваше приложение будет переписано на 90% несколько раз.

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

Answer 5

1. Нет, потому что статические методы сложно проверить
2. Это зависит от параметра, жизненного цикла и т. Д. Невозможно ответить, не увидев какой-либо код.
4. Нет

ООП требует не менее 10 лет опыта, чтобы иметь лучшее представление о том, что не так / правильно / лучше / хуже.

Итак, если вы не являетесь экспертом по ООП, вместо того, чтобы тратить слишком много времени на изобретение колеса, я бы предложил:

1. Использовать общеизвестные рамки для технической части
2. Создайте свои классы / рамки для бизнес / функциональной части.

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

(2) Это ваш основной бизнес, это должна быть «ваша ДНК».

Кроме того, использование хорошо известной / хорошей технической структуры заставит вас читать качественный код и поможет вам прогрессировать. (Будьте осторожны, некоторые фреймворки действительно низкого качества)

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