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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

О, и отсутствие ясности, которую вы находите в отношении класса модели, вероятно, связано с тем, что это часть вашего приложения, которая наиболее настраивается. Это ваша модель данных и логика домена, поэтому многие из них зависят от конкретного случая. Лучший ресурс, тем не менее, ИМХО - это Мартин Фаулер, чья отличная книга «Шаблоны архитектуры корпоративных приложений» содержит подробные сведения о том, как и почему создавать определенный набор «модельных» классов одним или несколькими образцами. Вот online pattern library - очевидно, книга более подробно.

Надеюсь, что несколько помогает.