В MVC, 1 таблице модели 1 или 1 модели несколько таблиц?
Я могу понять назначение функции сна, если вам приходится иметь дело с синхронным выполнением. Функции setInterval и setTimeout создают поток параллельного выполнения, который возвращает последовательность выполнения обратно в основную программу, что неэффективно, если вам приходится ждать заданного результата. Конечно, можно использовать события и обработчики, но в некоторых случаях это не то, что предназначено.
2 ответа
Обычно вы создаете одну модель для каждой таблицы, поэтому в вашем случае это означает, что вам нужно 3 модели. Когда я говорю «Модель», я имею в виду класс, который будет представлять одну строку (обычно) в одной таблице.
например: Таблицы:
- Продукты
- Заказы
- Клиенты
в этом случае самым простым и простым является создание 3 разных классов (которые представляют модель данных приложения), где первый класс представляет один продукт, next представляет заказ, а последний класс будет представлять одного клиента.
Как правило, часть MVC «Модель» следует интерпретировать как «Модель представления» или «Модель представления», то есть как класс, который инкапсулирует все данные и поведение, необходимые для Посмотреть. Это может быть или не быть эквивалентом модели предметной области.
Модели предметной области должны быть разработаны так, чтобы быть независимыми от UI. Это означает, что такие модели не должны загрязняться данными и поведением, специфичными для пользовательского интерфейса, такими как определение того, активирована ли конкретная кнопка.
Вы также можете захотеть показать одни и те же объекты домена в нескольких разных представлениях (например, Master / Detail или Display / Edit), и если эти представления существенно различаются, наличие модели представления для каждого представления будет полезным.
Таким образом, в общем, вы должны проектировать свой уровень домена и уровень представления независимо.
В уровень домена, вы можете смоделировать свои три таблицы как три класса. Такие книги, как Patterns of Enterprise Application Architecture и Evans Domain-Driven Design , содержат множество рекомендаций о том, как моделировать реляционные данные как модели предметной области.
Когда дело доходит до моделирования представлений в MVC имеет смысл создавать по одной модели для каждого представления. Такая модель представления может просто инкапсулировать один объект домена, но она также может инкапсулировать и агрегировать несколько различных объектов домена.
Таким образом, вы можете гарантировать разделение задач и то, что ваши классы следуют принципу единой ответственности.
] Для очень простых сценариев может иметь смысл объединить модель предметной области и модель представления в один уровень, но вы должны понимать, что по сути это означает, что '