Репозиторий в контроллере или модели?
Предполагая, что RType является типом перечисления с поддержкой char (или псевдонимом для некоторого типа char), вы можете memcpy внести свой вклад в объект record. Вы также можете заставить ваш компилятор делать то, что вы намереваетесь с помощью reinterpret_cast.
Однако проблема, с которой вы сталкиваетесь, звучит так, как будто вы наблюдаете значения в этом record объекте с помощью функций, которые принимают строки с нулевым символом в конце. Вместо этого вы должны использовать функции, которые принимают длину.
printf("r.m_rectype = \"%d\"", r.m_rectype);
printf("r.m_recordname = \"%11.11s\"", r.m_recordname);
printf("r.m_recordNo = \"%d\"", r.m_recordNo);
printf("r.m_record_date = \"%6.6s\"", r.m_record_date);
5 ответов
"Модель" в mvc - это презентационная модель, а не модель предметной области. Контроллер - единственный субъект, связанный с уровнем обслуживания.
Репозиторий - это проблема инфраструктуры. Вы заставляете модель полагаться на вашу инфраструктуру. Это своего рода обратный способ сделать это. Это означает, что если вы хотите сделать что-то вроде внедрения зависимостей, вам придется разрешить модель из вашего контейнера, что для меня не имеет большого смысла.
Кроме того, суть не в том, чтобы хранить все в одном месте. Вы должны стремиться к тому, чтобы ваши проблемы были разделены на логические единицы. Таким образом, вы можете легко определить, какая часть приложения чем занимается. Он также поддается тестированию.
Я бы сказал, что не учетная запись выполняет вход, а вы используете учетную запись для входа в приложение , поэтому вызов метода входа в учетную запись кажется немного неестественно.
В Domain Driven Design есть место для бизнес-логики, которая не вписывается в класс Account: это называется сервисом. Вы можете узнать больше об услугах DDD, например, здесь .
Я бы не хотел помещать ваш доступ к данным внутри вашей модели. Вполне возможно, что это может привести к зависимости модели от механизма хранения. Я обычно помещаю эту логику на уровень сервисной / бизнес-логики, который будет разговаривать с уровнем данных и моделями. В вашем случае с только моделью и контроллером эту работу выполняет контроллер.
Я думаю о модели предметной области как о группе игрушек или инструментов, которые вы подбираете, используете, манипулируете и т.д. на самом деле мне все равно, где они хранятся, да и не стоит. У вас должна быть возможность положить игрушку на полку или в ящик для инструментов. На игрушку это не влияет.
У вас должен быть как минимум еще один уровень (не контроллер), который отвечает за взаимодействие с интерфейсом репозитория. Thil позволяет поменять один интерфейс (контроллер является его частью) на другой. Таким образом, не имеет значения, будет ли это командная строка, рабочий стол или веб-интерфейс.
В ASP.NET MVC я предпочитаю иметь модель (не модель моей предметной области, модель MVC) в отдельном проекте, а не в MVC. Это позволяет использовать DTO (модель MVC) с другими типами UI.