Каковы принципы позади, и преимущества, “партийная модель”?
Ваша проблема не связана с VueJS / ThreeJs (снова ^^), вы должны научиться использовать this внутри обратного вызова, вот исправление E6:
texture.load( require( "./clouds.png" ), t => this.onSuccess(t), e => this.onProgress(e), e => this.onError(e) )
https : //developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
4 ответа
- Каковы базовые принципы и мотивирующие силы позади партийной модели?
До такой степени, что я использовал его, это главным образом о повторном использовании кода и гибкости. Мы использовали его прежде в госте / пользователь / администраторская модель, и, конечно, оказывается свое значение, когда необходимо переместить пользователя от одной группы другому. Расширьте это до наличия организаций и компаний, представленных с пользователями под ними, и оно действительно обеспечивает форму абстракции, которая не особенно свойственна от SQL.
- Что это предписывает, чтобы Вы сделали к своей модели данных? (Мой бит выше является довольно высоким уровнем и вполне возможно неправильный до некоторой степени. Я был на проекте, который использовал его, но я работал с отдельной командой, сфокусированной на других проблемах).
Вы довольно корректны в своем бите выше, хотя требуется еще некоторую деталь. Можно вообразить ситуацию, где объект в базе данных (называют это Стороной) выходит другой Стороне, которая может в свою очередь заключить субподрядный договор на работу. Сторона могла бы быть Сотрудником, Подрядчиком, или Компанией, всеми подклассами Стороны. От моего понимания у Вас были бы таблица Party и затем более определенные таблицы для каждого подкласса, который мог затем быть далее разделен на подклассы (Сторона-> Человек-> Подрядчик).
- Что Ваш опыт привел Вас чувствовать об этом? Вы использовали его, и если так, Вы сделаете так снова? Каковы были за и против?
Это обладает своими преимуществами, если необходимо гибко добавить новые типы к системе и создать отношения между типами, которые Вы не ожидали вначале и архитектор в (пользователи, перемещающиеся в новый уровень, компании, нанимающие другие компании, и т.д.). Это также приносит Вам пользу выполнения единого запроса и получения данных для нескольких типов сторон (Компании, Сотрудники, Подрядчики). На обороте Вы добавляете дополнительные слои абстракции для получения до данных, Вы на самом деле нуждаетесь и увеличиваете загрузку (или по крайней мере количество соединений) на базе данных, когда Вы запрашиваете для определенного типа. Если Ваша абстракция зайдет слишком далеко, то необходимо будет, вероятно, выполнить несколько запросов для получения данных, поскольку сложность начала бы становиться вредной для загрузки базы данных и удобочитаемости.
- Партийная модель ограничивала Ваш выбор ORMs? Например, необходимо ли было устранить определенный ORMs, потому что они не допускали действительно "уровень абстракции" между объектами области и физической моделью данных?
Это - область, в которой я по общему признанию немного слаб, но я нашел, что использование представлений и зеркально отразило абстракцию на прикладном уровне, не сделали это слишком большой проблемы. Настоящая проблема для меня всегда была, "где является часть данных X проживанием", когда я хочу считать источник данных непосредственно (это не всегда интуитивно для новых разработчиков в системе любой).
Я не уверен, но партийная модель походит на особый случай шаблона специализации обобщения. Поиск на "специализации обобщения реляционное моделирование" находит некоторые интересные статьи.
Это обширная тема, я бы рекомендовал прочитать Книга ресурсов модели данных, том 3 - Универсальные шаблоны для моделирования данных Лена Сильверстона и Пола Агнью.
Я только что получил свою копию, и она довольно хороша - она дает вам возможность забыть о многих подходах к моделированию данных, включая гибридные контекстные шаблоны ролей и так далее. Он содержит подробные сведения о плюсах и минусах для каждого подхода.
Существует множество способов моделирования партийных отношений и ролей со всеми их преимуществами и недостатками. Вопрос, который был принят в качестве ответа, охватывает только один случай «партийной модели».
Например, во многих подходах такие понятия, как «Сотрудник», «Менеджер проекта» и т. Д., Являются ролями , которые партия может играть в определенном контексте.
Когда я был частью команды, реализующей эти идеи в начале 1980-х, это не ограничивало наш выбор ORM, потому что они еще не были изобретены.
Я бы отступил. об этих идеях в любое время, так как этот конкретный проект был одним из самых убедительных доказательств концепции "революционной" идеи, которую я когда-либо видел (которая определенно была в то время).
Это ни к чему не принуждает. И это не останавливает вас ни от чего (я имею в виду от любой ошибки). Тот, кто определяет вашу собственную информационную модель, - это вы.
У всех сторон есть много общих свойств. Дело в том, что у них есть имя и тому подобное (мы называли их "сигналетиками"). Тот факт, что у них есть основные / основные местоположения, называемые «адресами». Дело в том, что все они в каком-то смысле вовлечены в бизнес-контракты.