Одна база данных или многие?
Ваш атрибут [Remote] не работает, потому что вы создаете вход с
<input type="text" name="InsertUser.FullName" .... >
, но отправляете его методу с параметром string FullName. Один из способов решения этой проблемы - использовать атрибут [Bind] для префикса
public JsonResult CheckUserName([Bind(Prefix="InsertUser")]string FullName)
, чтобы значение было правильно привязано. Однако лучшим способом является использование модели представления только с теми свойствами, которые вам нужны в представлении, которые из показанного вами представления выглядят только FullName и LastName, и избегают использования атрибута [Bind].
Ваш метод POST также включает вызов CheckUserName(vmModel.InsertUser.FullName);, который возвращает JsonResult, что не имеет смысла. Предполагая, что вы хотите иметь удаленную проверку на стороне клиента и повторить проверку, когда вы отправляете, вы должны реорганизовать свой код на 2 метода
private bool IsNameValid(string FullName)
{
return Json(!db.Users.Any(x => x.FullName == FullName), JsonRequestBehavior.AllowGet);
}
public JsonResult CheckUserName(string FullName)
{
return Json(IsNameValid(FullName), JsonRequestBehavior.AllowGet);
}
, а затем в методе POST
[HttpPost]
public ActionResult Create(VMUsers vmModel)
{
if (!IsNameValid(vmModel.InsertUser.FullName)
{
ModelState.AddModelError("InsertUser.FullName", "Fullname exists");
}
if (!ModelState.IsValid)
{
return View(vmModel);
}
// save and redirect
}
11 ответов
Лично, я предпочитаю отдельные базы данных, конкретно база данных для каждого объекта. Мне нравится этот подход по следующим причинам:
- Меньший = быстрее относительно запросов.
- Запросы более просты.
- Никакой риск когда-либо случайного отображения данных одного клиента другому.
- Одна база данных могла изложить узкое место производительности, поскольку это становится большим (# увеличения объектов). Вы получаете своего рода сборку в горизонтальной масштабируемости с 1 на объект.
- Легкие данные моются как клиенты, или объекты удалены.
Уверенный потребуется больше времени для обновления схемы, но по моему опыту модификации являются довольно редкими, после того как Вы развертываетесь, и дополнения тривиальны.
Я думаю, что на это трудно ответить без большей информации.
Я полагаюсь на сторону одной базы данных. Правильно кодированные бизнес-объекты должны препятствовать тому, чтобы Вы забыли clientId в своих запросах.
Тип базы данных, которую Вы используете и как это масштабируется, мог бы помочь Вам принять свое решение.
Поскольку схема изменяется в будущем, кажется, что одна база данных была бы легче с точки зрения обслуживания - у Вас есть одно место для создания их.
Что относительно резервного копирования и восстановления? Вы могли испытать клиента, желающего восстановить резервное копирование для одного из их объектов?
Один хороший аргумент для хранения их в отдельных базах данных - то, что его более легкое для масштабирования (у Вас может просто быть несколько установок сервера с клиентскими базами данных, распределенными через серверы).
Другой аргумент - то, что, после того как Вы зарегистрированы, Вы не должны добавлять дополнительное где проверка (для клиентского идентификатора) в каждом из Ваших запросов.
Так, основной DB, поддержанный несколькими DBS для каждого клиента, может быть лучшим подходом,
Проверьте эту статью о сайте Microsoft. Я думаю, что это делает хорошее задание разметки различных расходов и доходов, связанных с Многопользовательскими проектами. Также посмотрите на Много статью аренды о wikipedeia. Существуют, многие торгуют offs, и Ваше лучшее соответствие значительно зависит от того, какой продукт Вы разрабатываете.
Это - довольно нормальный сценарий в многопользовательских приложениях SaaS. Оба подхода имеют свои за и против. Поиск на лучших практиках для многопользовательской SaaS (программное обеспечение как сервис) и Вы найдете, что тонны материала обдумывают на.
Я думаю, что необходимо пойти с самым реалистическим сценарием и не обязательно, что клиент "может" хотеть сделать в будущем. Если Вы идете на рынок, что функция (т.е. видящий все Ваши объекты в одной панели инструментов), то необходимо или найти решение (возможно, имеют получение по запросу панели инструментов от нескольких баз данных) или использует единую базу данных для целого приложения.
По моему скромному мнению, наличие данных для нескольких клиентов в той же базе данных просто походит на плохую идею мне. Необходимо будет не забыть всегда фильтровать запросы clientID.
Если клиент должен был бы когда-либо восстанавливать только единственный объект от резервного копирования и оставлять другие в их текущем состоянии, то обслуживание будет намного легче, если каждый объект будет в отдельной базе данных. если они могут быть сохранены и восстановлены вместе, то может быть легче поддержать объекты как единую базу данных.
Это также зависит от вашей СУБД, например
С SQL серверные базы данных дешевы
С Oracle легко разделить таблицы по «идентификатору клиента», так что одна большая база данных может работать так же быстро, как маленькая база данных для каждого клиента.
Каким бы ни был ваш выбор, постарайтесь скрыть это как низкий уровень в вашем коде доступа к данным
Планируете ли вы развернуть свой код в нескольких средах?
Если да, то попытайтесь сохранить его в одной базе данных, а все ссылки на таблицы должны иметь префикс пространства имен из файла конфигурации.
Использование единой базы данных значительно упростило бы обслуживание.