MVC: Представление и Взаимодействие Модели Относительно Доступа к данным, и т.д.
Когда вы вызываете pandas.read_csv, вы можете использовать регулярное выражение, которое соответствует нулевому или более пробелам, за которым следует запятая, а в качестве разделителя - ноль или более пробелов.
Например, здесь "data.csv" :
In [19]: !cat data.csv
1.5, aaa, bbb , ddd , 10 , XXX
2.5, eee, fff , ggg, 20 , YYY
(Первая строка заканчивается тремя пробелами после XXX, а вторая строка заканчивается последним Y.)
Следующие использует pandas.read_csv() для чтения файлов с регулярным выражением ' *, *' в качестве разделителя. (Использование регулярного выражения в качестве разделителя доступно только в механизме «python» read_csv().)
In [20]: import pandas as pd
In [21]: df = pd.read_csv('data.csv', header=None, delimiter=' *, *', engine='python')
In [22]: df
Out[22]:
0 1 2 3 4 5
0 1.5 aaa bbb ddd 10 XXX
1 2.5 eee fff ggg 20 YYY
4 ответа
Обычно я реализую MVC следующим образом:
Представление - Получает данные из контроллера и генерирует вывод. Вообще только логика дисплея должна появиться здесь. Например, если бы Вы хотели взять существующий сайт и произвести мобильную версию / версию iPhone ее, необходимо быть в состоянии сделать это только путем замены представлений (предполагающий желание той же функциональности).
Модель - доступ Обертки к данным в моделях. В моих приложениях, всех жизнях SQL в уровне Model, никакой прямой доступ к данным не позволяется в Представлениях или Контроллерах. Как Elie указывает в другом ответе, идея здесь к (по крайней мере, частично), изолируют Ваши Контроллеры/Представления от изменений в структуре базы данных. Модели являются также хорошим местом для реализации логики, такой как обновление "последней измененной" даты каждый раз, когда поле изменяется. Если главный источник данных для Вашего приложения является внешним веб-сервисом, рассмотрите ли, обернув это в образцовый класс.
Контроллеры - Используемый для склеивания Моделей и Представлений. Реализуйте прикладную логику здесь, проверьте формы, передайте данные от моделей до представлений, и т.д.
, Например, в моих приложениях, когда страницу будут требовать, контроллер выберет любые данные, требуется от моделей, и передайте его представлению для генерации страницы, которую видит пользователь. Если та страница была формой, форма может тогда быть отправлена, контроллер обрабатывает проверку, создает необходимую модель и использует его для сохранения данных.
, Если Вы следуете этому методу, Модели заканчивают тем, что были довольно универсальными и допускающими повторное использование. Ваши контроллеры имеют управляемый размер и сложность, потому что доступ к данным и дисплей были удалены к Моделям и Представлениям соответственно, и Ваши представления должны быть достаточно простыми, что разработчик (с небольшим обучением) мог постигать их.
Я не поместил бы Код Доступа к данным в Контроллер.
Для построения, что было уже сказано важно думать о разделении на уровни НА слоях. Например, у Вас, вероятно, будет несколько слоев в рамках самой Модели - Уровень доступа к данным, который выполняет любой ORM и Доступ к базе данных и более абстрактный слой, который представляет Бизнес-объекты (без любого ведома того, КАК получить доступ к их данным).
Это позволит Вам тестировать компоненты своей системы более легко, поскольку она поддерживает насмешку.
Мне нравится сохранять "контракты" или интерфейсы, для персистентности модели или сервисного доступа в доменном (образцовом) слое. Я поместил реализации доступа к данным или служебные вызовы в другом слое.
контроллеры инстанцируют с конструкторами, которые берут интерфейсы для служб, например, ISomeService, как параметры. Сами контроллеры не знают, как уровни служб реализованы, но они могут получить доступ к ним. Тогда я могу легко заменить SqlSomeService или InMemorySomeService.
я также был довольно доволен конкретной реализацией услуги, которая берет доменный (образцовый) репозиторий слоя в качестве параметра его конструктору.. Например: ICatalogRepository с SqlServerCatalogRepositry: ICatalogRepository вручают CatalogService (ICatalogRepository, ISomeOtherDependency).
Этот вид разделения легче с платформами внедрения зависимости.
Представление передало бы то, что должно произойти при щелчке в UI к уровню Control, который содержал бы ВСЮ бизнес-логику и в свою очередь назовет уровень Model, который только выполнил бы вызовы базы данных. Только образцовый слой должен выполнять вызовы базы данных, или Вы победите цель шаблона разработки MVC.
Думают об этом этот путь. Скажем, Вы изменяете свою базу данных. Вы хотели бы ограничить изменение объема кода, требуемое и держать все те изменения вместе, не влияя на другие части Вашего приложения. Таким образом путем хранения всего доступа к данным в уровне Model, даже простые вызовы, Вы ограничиваете любые изменения, требуемые уровнем Model. Если бы необходимо было обойти уровень Model по какой-либо причине, необходимо было бы теперь расширить любые изменения, необходимые до любого кода, который знает о базе данных, делая такое обслуживание более сложным, чем это должно быть.