Комментарии 36
Неплохо бы добавить к статье ссылку на репозиторий с кодом.
Начало статьи интересное. Добавил в закладки, дома дочитаю.
Ещё бы статью как сделать торрент клиент :-)
Ещё бы статью как сделать торрент клиент :-)
Посмотрите в сторону MonoTorrent. Говорят, что библиотека неплохая…
Вроде бы когда его смотрел, он еще и трекер внутри имел.
Я делал торрент клиент на ней. Библиотека действительно отличная, стабильная и няшная.
Если интересно, вот код, он старый, мелкий и специфичный.
Если интересно, вот код, он старый, мелкий и специфичный.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос такой, всё началось с «а вот сейчас мы создадим такую таблицу...», как будто использование БД в данном случае очевидное решение.
Нужна ли в данном случае БД, если данные в ней актуальны только короткий промежуток времени?
Или без БД нынче неприлично писать код?
Нужна ли в данном случае БД, если данные в ней актуальны только короткий промежуток времени?
Или без БД нынче неприлично писать код?
Статистика и рейтинги в планах, именно поэтому пример с БД, но тот функционал, который реализован в статье вполне мог бы обойтись и без нее… Получился бы BitStorm C# какой-нибудь :).
А это проще всего. Искаропки имеем хранилище, в которое можно писать-читать, без всякого траха с доступом, правами, локами и т.д. Если еще и положить поверх l2s — так еще и классы-сущности нахаляву(в таком проекте можно без всяких DTO прямо их везде и исспользовать). Чего еще для счастья надо?
А кроме «психологических»(из пушки по воробью и т.д.) аргументы есть?
А кроме «психологических»(из пушки по воробью и т.д.) аргументы есть?
Думаю, что автор комментария предлагал хранить данные в памяти, нет?
На запись в БД серьезные накладные расходы. Простые встраиваемые БД не держат многопоточность или держат, но со специфическими ухищрениями. Общее усложнение системы (нужно разруливать коннекты к БД).
А если речь идет о легковесной библиотеке, т.е. вероятно ее использование и там где ресурсов кот наплакал, то вопросы быстродействия нельзя отодвигать на второй план.
А если речь идет о легковесной библиотеке, т.е. вероятно ее использование и там где ресурсов кот наплакал, то вопросы быстродействия нельзя отодвигать на второй план.
XBTT на C++ написан, на нем почти все трекеры в сети работают. Почему именно C#?
Название public методов с маленькой буквы. Меня это огорчает :(
А почему должно быть с большой? Где почитать?
Потому что такое соглашение у .NET. И оно не просто от балды придумано, а используется в самом фреймворке. В WinRT, например, если в модуле на JavaScript название начинается со строчной буквы, то в других языках оно будет с прописной. Или наоборот, если на C++/C#/VB первая буква прописная, то в JavaScript этот метод будет вызываться со строчной.
Этот код выглядит так, будто он написан на пхп =\
Именно поэтому он здесь. Надеюсь на то, что вы поможете его доработать и укажите на явные ошибки.
Спасибо заранее.
Спасибо заранее.
Именно ошибок в коде не видно, и код, судя по всему, рабочий.
Но ужасно режет глаз стиль написания кода. Поэтому я бы предложил несколько его исправить, чтобы соответствовать Best Practices:
1) Именование переменных — об этом уже есть в комментариях выше
2) Не стоит называть переменные в стиле _object, _int и т.п. Во первых код будет странно подсвечиваться. Да и обычно просто не называют переменные зарезервированными ключевыми словами. Если очень хочется, то следует в этих случаях писать object или int, но лично я бы так делать все равно не стал. Лучше придумать какое-нибудь лаконичное название переменной :)
3) По БД — такое именование полей может быть уместно, но я бы тоже придерживался стиля именования, как и в программе
4) Написание RAW SQL-кода в программе это удел любителей пхп. Намного лучше использовать хранимые процедуры для любых действий с БД
5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
6) Вместо StringBuilder уместнее в данном случае использовать string.Format(...)
Так же прикладываю ссылочку на код для удобной работы с хранимыми процедурами из кода:
pastebin.com/j5EkmDuH
Но ужасно режет глаз стиль написания кода. Поэтому я бы предложил несколько его исправить, чтобы соответствовать Best Practices:
1) Именование переменных — об этом уже есть в комментариях выше
2) Не стоит называть переменные в стиле _object, _int и т.п. Во первых код будет странно подсвечиваться. Да и обычно просто не называют переменные зарезервированными ключевыми словами. Если очень хочется, то следует в этих случаях писать object или int, но лично я бы так делать все равно не стал. Лучше придумать какое-нибудь лаконичное название переменной :)
3) По БД — такое именование полей может быть уместно, но я бы тоже придерживался стиля именования, как и в программе
4) Написание RAW SQL-кода в программе это удел любителей пхп. Намного лучше использовать хранимые процедуры для любых действий с БД
5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
6) Вместо StringBuilder уместнее в данном случае использовать string.Format(...)
Так же прикладываю ссылочку на код для удобной работы с хранимыми процедурами из кода:
pastebin.com/j5EkmDuH
А чем Singleton-кеш не угодил и LINQ? Для таких простых вещей процедуры использовать, что с пушки по воробьям стрелять.
Процедуры позволяют вывесить только их «в мир», а ко всем таблицам закрыть доступ. Это существенно повышает безопасность. Также удобно изменять процедуры, не пересобирая весь проект. Да и SQL-иньекцию в процедуру сделать сложнее.
И причем здесь LINQ? Может быть имелось в виду Linq2Sql? В целом он неплох, но тогда уж лучше использовать современных Entity Framework
И причем здесь LINQ? Может быть имелось в виду Linq2Sql? В целом он неплох, но тогда уж лучше использовать современных Entity Framework
Кстати, ваши процедуры весьма похожи на мои, например вот:
public DataTable fill(string command_text, Dictionary<string, object> parameters, CommandType command_type)
{
string connection_string = System.Web.Configuration.WebConfigurationManager.ConnectionStrings["connection_string"].ConnectionString;
using (SqlConnection sql_connection = new SqlConnection(connection_string))
{
using (SqlDataAdapter sql_data_adapter = new SqlDataAdapter(command_text, sql_connection))
{
if (parameters != null)
{
foreach (KeyValuePair<string, object> parameter in parameters)
{
sql_data_adapter.SelectCommand.Parameters.AddWithValue(parameter.Key, parameter.Value);
}
}
sql_data_adapter.SelectCommand.CommandType = command_type;
using (DataTable data_table = new DataTable())
{
sql_data_adapter.Fill(data_table);
return data_table;
}
}
}
}
>4) Написание RAW SQL-кода в программе это удел любителей пхп. Намного лучше использовать хранимые процедуры для любых действий с БД
Это ключевым образом зависит от типа используемой БД и оболочки. Тот же SQLite их практически не поддерживает. Да и для отдельных баз значительная часть логики в хранимых процедурах — это очень спорный вопрос.
>5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
Вкусовщина. Обычно вары любят там, где много LINQ.
Это ключевым образом зависит от типа используемой БД и оболочки. Тот же SQLite их практически не поддерживает. Да и для отдельных баз значительная часть логики в хранимых процедурах — это очень спорный вопрос.
>5) При объявлении переменных непохо бы использовать ключевое слово var, а не явное указание типа переменной — это на любителя, конечно
Вкусовщина. Обычно вары любят там, где много LINQ.
По п. 4 — я использую хранимые процедуры, но показывать их в простейшем примере просто не счел нужным. Равно как и показывать индексы и т.п. Это ведь не учебник по T-SQL.
По п. 5 — почему var? Всегда считал, что явное указание типов лучше. Или нет? Расскажите про этот момент поподробнее.
Спасибо.
По п. 5 — почему var? Всегда считал, что явное указание типов лучше. Или нет? Расскажите про этот момент поподробнее.
Спасибо.
Вообще использование var это исключительно дело вкуса, но например, тот же решарпер ругается, если явно указываешь тип там, где можно было использовать var.
Вот несколько причин, почему использование var может оказаться удобнее:
1) в циклах foreach var писать порой намного легче, чем руками определить тип элементов коллекции
2) в случае, когда написал одно, а потом передумал и написал другое, var может избавить от изменения нескольких кусков кода
3) иногда var выглядит более лаконично, если переменная объявляется какого-то сложного вложенного типа.
На самом деле тут сложно сказать, что лучше, а что нет. Но насколько мне известно, сейчас более «модно» что ли писать var
Вот несколько причин, почему использование var может оказаться удобнее:
1) в циклах foreach var писать порой намного легче, чем руками определить тип элементов коллекции
2) в случае, когда написал одно, а потом передумал и написал другое, var может избавить от изменения нескольких кусков кода
3) иногда var выглядит более лаконично, если переменная объявляется какого-то сложного вложенного типа.
На самом деле тут сложно сказать, что лучше, а что нет. Но насколько мне известно, сейчас более «модно» что ли писать var
Я когда увидел, вообще думал что это сяшный идовский декомпил :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BitTorrent Tracker на C#