Это может быть действительно глупый вопрос, но у меня нет ясного представления о том, как лучше всего с этим справиться, поэтому хочу изложить это здесь и посмотреть, что является обычной практикой.
Исходя из .net, мои веб-приложения никогда не являются одним проектом, и это все, у меня есть, по крайней мере, проект уровня данных, который имеет дело с постоянными сущностями в базе данных, и эти модели представляют собой сущность в БД дружественным образом. Затем у меня есть свой проект пользовательского интерфейса, который имеет свои собственные модели, которые представляют собой объект для пользовательского интерфейса, который может иметь информацию, основанную на проверке, и, скорее всего, будет более урезанной моделью, показывающей только то, что необходимо.
Таким образом, основной момент, который я пытаюсь здесь подчеркнуть, заключается в том, что, хотя у нас может быть сущность User, модели для представления могут немного отличаться на уровнях пользовательского интерфейса и данных ...
Теперь ускоренная перемотка на rails, вы создаете свой проект, и он поставляется с подключением к базе данных (которое, я считаю, может быть заменено на любой вкус), проверкой и множеством других структур и функциональных возможностей. Тогда это, по-видимому, означает, что мне больше не нужны 2 проекта, только 1, поскольку все они включены в этот список и все для меня сделано, поэтому все, о чем мне нужно беспокоиться, - это создание моих моделей.
Это та часть, где я немного запутался, так как предположим, что я использую ActiveRecord. Мне нужно будет сделать свою модель и наследовать от ActiveRecord :: Base, затем мне нужно будет настроить, как эта модель соединяется с другими моделями и т. Д. Итак, у меня отсортированы проблемы с данными моей модели, теперь мне нужно настроить проблемы с пользовательским интерфейсом, о проверке, длине строк и т. д. Теперь, куда они идут ... Я предполагаю, что на той же модели, но тогда модель не просто простое представление данных, это блок stuff , содержащий сведения о базах данных и представлениях, и кто знает, что еще.
Просто немного странно складывать все в одном месте. Я знаю, что в .net есть много примеров, когда с большими представлениями графов объектов в БД модели данных ОЧЕНЬ отличаются от моделей пользовательского интерфейса, поэтому разумно ли объединить их в одну модель таким образом, или Ruby и его фреймворки настолько гибки в этой области, что у вас нет таких же проблем? Если да, то есть ли какой-нибудь пример или статья, которая может помочь мне понять, как вы обходите обычные проблемы, которые заставляют вас разделить ваши проблемы, чтобы иметь поддерживаемый код ...
=== Редактировать ===
Просто чтобы попытаться устранить любую путаницу, в своем посте, когда я говорю о моделях представления и проблемах представления, я не имею в виду проблемы представления. Прошу прощения, если это встретилось таким образом. Я имею в виду, что у меня может быть (в обычном примере .net) модель UserStorage, которая имеет отношение к сохранению сущности User. Затем в слое пользовательского интерфейса отображается представление, отображающее множество пользователей, и представление, отображающее отдельных пользователей более подробно. У вас могут быть две разные модели: модель UserSummary и модель UserDetails, которые частично представляют сущность пользователя, но настроены для конкретного рассматриваемого представления, поскольку вы можете столкнуться с ситуацией, когда UserDetails также становится композицией пользователя и Субъект компании, что означает, что есть 2 класса на основе хранилища, которые подаются в 1 класс на основе представления.
В примерах и руководствах он показывает, что у вас должна быть 1 модель представления, которая занимается этими проблемами, а также проблемами хранения, и в этом случае просто кажется, что я оказался в ситуации, когда у меня была модель представления это был класс User и Company, и было бы странно, чтобы этот класс слоя представления беспокоился о своем хранилище, поскольку он никогда не сохраняется как сам по себе, он хранится как две отдельные модели в базе данных / хранилище данных.
Это НАСТОЯЩАЯ проблема, которую я пытаюсь решить, похоже, она тесно связывает ваше видение с вашими проблемами хранения, которые я привык называть двумя разными вещами, которые никогда не должны смешиваться ... например, ставить ваш основной курс и пудинг на одной тарелке ...