Обновить запись Linq-to-SQL - PullRequest
Новая
       13

Обновить запись Linq-to-SQL

3 голосов
/ 31 октября 2011

Я читаю книгу - ASP.Net 3.5 Разработка корпоративных приложений с помощью Visual Studio 2008, и когда он говорит об обновлении записи в базе данных с использованием Linq-to-SQL, он использует этот код: 

MyUserAccount ua = new MyUserAccount
{
... Update fields
};

ua.UserAccountID = Convert.ToInt32(session["UserAccountID"]);
ua.Version = Convert.ToInt32(session["Version"]);

MyDataContext db = new MyDataContext();
db.MyUserAccounts.Attach(ua,true);
db.SubmitChanges();

По сравнению с тем, к чему я привык, где я просто сохраняю AccountID в переменной сеанса а затем получите запись из базы данных, внесите мои изменения и отправьте изменения.

BtnUpdate 

int UserAccountID = Convert.ToInt32(Request["UserAccountID"]);

//Get User fron Context
MyDataContext db = new MyDataContext();
MyUserAccount ua = db.MyUserAccounts.Single(
     x => x.UserAccountID == UserAccountID);

//Make changes
ua.Blah = "";

db.SubmitChanges();

Итак, мой вопрос: каков предпочтительный способ сделать это? Не видя этого в прошлом, я не уверен, какой это предпочтительный или лучший способ. Любая помощь приветствуется.

Wade

Примечание:

Мой первоначальный вопрос, кто-то изменил мой заголовок, был лучшим способом обновления записи в Linq-to-SQL. Поэтому я изменил код, чтобы использовать переменные сеанса и заголовок обратно на оригинал. Пожалуйста, прочитайте весь вопрос, так как я ищу только лучший способ обновить мою запись в базе данных, используя Linq-to-SQL.

Ответы [ 4 ]

1 голос
/ 31 октября 2011

С точки зрения созданного sql, первое сгенерирует оператор Sql, например, 

Update MyUserAccount set blah=@Blah where UserAccountID = @UserAccountID

тогда как последний произведет 

Select UserAccountID, Blah, ....  From MyUserAccount where UserAccountID = @UserAccountID
Update MyUserAccount set blah=@Blah where UserAccountID = @UserAccountID
1 голос
/ 31 октября 2011

Не делайте ничего, сохраняйте критически важные данные в этом сеансе. Скрытые поля (viewstate - это скрытое поле) могут быть изменены пользователем. Сеанс не позволит пользователю изменить значение.

0 голосов
/ 31 октября 2011

Viewstate добавляет немного шифрования к данным, так что вы не сможете легко их подделать, а не будете делать это с необработанным скрытым полем.Наилучший подход к информации о пользователе - хранить ее в сеансе.

0 голосов
/ 31 октября 2011

Пример из книги хранит данные useraccount и информацию о версии в viewstate - это большое скрытое поле, которое asp.net использует для сохранения состояния и хранения переменных формы. Фактически ваше скрытое поле будет вероятно, вы находитесь в viewstate, если у вас включено viewstate.

Если вы выключите viewstate и используете свое скрытое поле, то страница, вероятно, будет загружаться быстрее (из-за раздувания, связанного с поддержанием viewstate). Но это может повлиять на функциональность.

Кроме того, оператор linq to sql в вашем коде будет генерировать результат, отличный от книги - поэтому я предполагаю, что код книги не будет обновляться так, как вы захотите, без адаптации к вашим потребностям.

@ Мэтью прав, если у вас есть проблемы с безопасностью, тогда скрытое поле в виде открытого текста - плохое место для хранения чего-либо (+1).

...