2015-03-02 1 views
0

Хорошо, поэтому я всегда читал, что в ASP.NET MVC всегда нужно ставить бизнес-логику в модели. Так скажем, у меня есть этот класс модели:Если модель должна содержать всю бизнес-логику, каков наилучший способ вызова методов класса в модели? (больше внутри)

public class CarModel 
{ 
     [Display(Name = "Car Manufacturer")] 
     [Required(ErrorMessage = "A Car Manufacturer is required")] 
     public string CarManufacturer { get; set; } 

     [Display(Name = "Car Year")] 
     public int CarYear{ get; set; } 
} 

Как добавить метод к этой модели, а затем запустить метод на примере этой модели? То, что я имею в виду, позволяет сказать, что у меня есть новый экземпляр вроде этого:

CarModel MyCar = new CarModel(); 

Как я хотел бы добавить метод к этой модели, а затем запустить метод на моем новом MyCar экземпляра модели? Могу ли я сделать что-то вроде:

MyCar.MyModelMethod(); 

Если да, то как бы я закодировать метод модели, чтобы для такого рода вызовом?

+0

Вы пробовали путь к публикации? –

+0

«в модель всегда следует ставить бизнес-логику« Я НИКОГДА НИКОГДА не буду этого делать. Я бы написал «другие классы», чтобы использовать модели ..... что происходит, когда 4 «модели» необходимы для принятия бизнес-решения, куда вы собираетесь его поместить? – granadaCoder

+0

Возможно, вы, скорее всего, не закодировали бы это в модели, а использовали расширения. Кроме того, одна ложь, на которую нужно обратить внимание, - это изменение классов POCO, созданных EF, вам следует либо отринуть эту модель на постоянные классы, либо просто работать с режимами просмотра, используемыми для ваших представлений. А что касается размещения бизнес-логики в модели (не видел, что минуту назад), нет. Это нормально, чтобы положить его в контроллеры. –

ответ

2

Есть два аспекта этого. Есть шаблон MVC , а затем есть ASP.NET MVC, структура, которая в большей или меньшей степени реализует шаблон MVC.

В MVC модель представляет собой гавань всей бизнес-логики. Однако ASP.NET MVC действительно не имеет концепции модели. Классы, которые часто называются «Модели», на самом деле являются просто сущностями, ваши POCOs, привязанные к таблицам базы данных. Это плохое оправдание моделей MVC в стиле, поэтому большинство разработчиков дополняют их двумя другими концепциями: просматривать модели и уровень доступа к данным или DAL.

Просмотреть модели - это всего лишь классы, но в частности они являются классами, которые вы создаете специально для целей одного или нескольких видов. Они часто представляют собой некоторый класс сущностей, но у них будут другие свойства и методы, которые не подходят для добавления в класс сущности. В ваших действиях вы сопоставляете свои объекты с/из этих моделей представлений, создавая разделение проблем: объект может относиться только к потребностям базы данных, а модель представления может относиться только к потребностям представления.

DAL - это место, где у вас будут хранилища или классы обслуживания. Они будут придерживаться логики, характерной для работы с вашими классами сущностей. Сущность просто хранит данные, тогда как ваш DAL определяет, как эти данные извлекаются, сохраняются и т. Д.

Вместе эти три (сущности, модели просмотра и репозитории/службы) составляют MVC-модель.

Смежные вопросы