Привет. Я согласен с
@foxmuldercp - материалы полезные.
static-поле в контроллере - худшее из возможных решений. Архитектура MVC предполагает наличие модели, которую вы игнорируете. Контроллер должен работать с неким репозиторием в части извлечение и сохранения данных. Приведу упрощенный пример
public interface IUsersRepository
{
UserInfo SaveUserInfo(UserInfo user);
IReadOnlyCollection<UserInfo> GetUsers();
}
В этом случае ваш контроллер может выглядеть следующим образом:
(Это тестовый пример, на практике нужно использовать
DI через
IoC-контейнер для внедрения репозитория)
public class HomeController : Controller
{
private readonly IUsersRepository _usersRepository;
public HomeController()
{
_usersRepository = new UsersRepository();
}
public ActionResult Index()
{
var users = _usersRepository.GetUsers();
return View(users);
}
public ActionResult Create()
{
return View();
}
[HttpPost]
public ActionResult Create(UserInfo userInfo)
{
if (ModelState.IsValid)
{
_usersRepository.SaveUserInfo(userInfo);
Users.Add(userInfo);
return RedirectToAction("Index");
}
return View();
}
}
При этом работа по сохранению пользователей переносится на реализацию интерфейса IUsersRepository. В зависимости от ваших потребностей, вы можете реализовать хранение коллекции пользователей в БД, в файле на диске, в оперативной памяти (для этого нужно либо сделать репозиторий
синглтоном, либо заговнокодить статическую коллекцию в нём).
Несколько замечаний напоследок:
1. Репозитории обычно отвечают за работу с конкретным хранилищем данных на уровне сохрани/удали/извлеки, а места для бизнес-логики не остаётся. Поэтому звеньев может быть еще больше - есть сервис бизнес-логики для работы с пользователями, который через репозиторий извлекает данные, а после формирует модель для отдачи контроллеру. Таким образом из класса
EF code first Person может формироваться модель UserInfo.
2. Еще раз напомню про материалы
@foxmuldercp , которые на начальных этапах изучения mvc могут быть очень полезны.
