Вообще использование var это исключительно дело вкуса, но например, тот же решарпер ругается, если явно указываешь тип там, где можно было использовать var.
Вот несколько причин, почему использование var может оказаться удобнее:
1) в циклах foreach var писать порой намного легче, чем руками определить тип элементов коллекции
2) в случае, когда написал одно, а потом передумал и написал другое, var может избавить от изменения нескольких кусков кода
3) иногда var выглядит более лаконично, если переменная объявляется какого-то сложного вложенного типа.
На самом деле тут сложно сказать, что лучше, а что нет. Но насколько мне известно, сейчас более «модно» что ли писать var
Процедуры позволяют вывесить только их «в мир», а ко всем таблицам закрыть доступ. Это существенно повышает безопасность. Также удобно изменять процедуры, не пересобирая весь проект. Да и SQL-иньекцию в процедуру сделать сложнее.
И причем здесь LINQ? Может быть имелось в виду Linq2Sql? В целом он неплох, но тогда уж лучше использовать современных Entity Framework
Именно ошибок в коде не видно, и код, судя по всему, рабочий.
Но ужасно режет глаз стиль написания кода. Поэтому я бы предложил несколько его исправить, чтобы соответствовать Best Practices:
1) Именование переменных — об этом уже есть в комментариях выше
2) Не стоит называть переменные в стиле _object, _int и т.п. Во первых код будет странно подсвечиваться. Да и обычно просто не называют переменные зарезервированными ключевыми словами. Если очень хочется, то следует в этих случаях писать object или int, но лично я бы так делать все равно не стал. Лучше придумать какое-нибудь лаконичное название переменной :)
3) По БД — такое именование полей может быть уместно, но я бы тоже придерживался стиля именования, как и в программе
4) Написание RAW SQL-кода в программе это удел любителей пхп. Намного лучше использовать хранимые процедуры для любых действий с БД
5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
6) Вместо StringBuilder уместнее в данном случае использовать string.Format(...)
Так же прикладываю ссылочку на код для удобной работы с хранимыми процедурами из кода: pastebin.com/j5EkmDuH
Вообще не очень понимаю смысла тестов. Если тест предназначен для того, чтобы отлавливать ошибки, которые программист предусмотрел, то зачем это нужно? Обычно все же код работает верно на тех данных, для которых он писался, а сыпется там, где что-то не предусмотрели. Если код сыпется на данных, под которые он делался без редких каких либо странных юз-кейсов, то это печально, тут уже мало что поможет. А как написать тест, который будет отлавливать ошибки на непредусмотренных кейсах, если кейс непредусмотрен? :)
Надеюсь, выразился понятно
И зачем ставить винду, чтобы потом развернуть на ней всякую ересь типа *AMP?
Если уж пользоваться виндой, то вместе с IIS. А для всего остального есть линуксы, они для этого подходят много лучше
Вот несколько причин, почему использование var может оказаться удобнее:
1) в циклах foreach var писать порой намного легче, чем руками определить тип элементов коллекции
2) в случае, когда написал одно, а потом передумал и написал другое, var может избавить от изменения нескольких кусков кода
3) иногда var выглядит более лаконично, если переменная объявляется какого-то сложного вложенного типа.
На самом деле тут сложно сказать, что лучше, а что нет. Но насколько мне известно, сейчас более «модно» что ли писать var
И причем здесь LINQ? Может быть имелось в виду Linq2Sql? В целом он неплох, но тогда уж лучше использовать современных Entity Framework
Но ужасно режет глаз стиль написания кода. Поэтому я бы предложил несколько его исправить, чтобы соответствовать Best Practices:
1) Именование переменных — об этом уже есть в комментариях выше
2) Не стоит называть переменные в стиле _object, _int и т.п. Во первых код будет странно подсвечиваться. Да и обычно просто не называют переменные зарезервированными ключевыми словами. Если очень хочется, то следует в этих случаях писать object или int, но лично я бы так делать все равно не стал. Лучше придумать какое-нибудь лаконичное название переменной :)
3) По БД — такое именование полей может быть уместно, но я бы тоже придерживался стиля именования, как и в программе
4) Написание RAW SQL-кода в программе это удел любителей пхп. Намного лучше использовать хранимые процедуры для любых действий с БД
5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
6) Вместо StringBuilder уместнее в данном случае использовать string.Format(...)
Так же прикладываю ссылочку на код для удобной работы с хранимыми процедурами из кода:
pastebin.com/j5EkmDuH
Насколько я знаю, Windows Server обычно не ставят на планшеты. Или я уже отстал от прогресса?
Надеюсь, выразился понятно
Если уж пользоваться виндой, то вместе с IIS. А для всего остального есть линуксы, они для этого подходят много лучше