> подключают и System.Web
Это не "тот же" system.web, что и в ранних версиях. В том смысле, что в новом asp.net этот system.web будет таким же опциональным, как и многие другие компоненты. Возможно стоит поискать минималистичный туториал. Или даже лучше туториал с других фреймворком, например с Нэнси: https://github.com/NancyFx/Nancy/wiki/Hosting-nanc... - здесь system.web уже не подключают, т.к. он НЕ НУЖЕН - мы вообще не используем ASP.Net. Ранее без ASP.Net обойтись можно было, только если самому реализовать еще и веб-сервер, ну или какой-нибудь fastcgi, и принимать входящие сетевые подключения. С OWIN можно использовать любой совместимый веб-сервер (IIS, self-hosting, как вы уже правильно заметили) с любым OWIN-приложением. Помимо того, что можно выбрать любой фреймворк, есть еще возможность добавлять так называемые middleware, через которые будет проходить http-запрос перед тем как попасть в основное приложение.
> В каких практических ситуациях необходимо оторваться от IIS?
Ну не знаю как у вас, а мне например неудобно арендовать сервер с виндой только ради IIS. PostgreSQL крутится на линухе, монга тоже, Mono сам по себе запускается нелохо, а вот для asp.net нужен бубен. Сейчас это стало неудобно даже для MS, т.к. теперь их важный доход - это Ажура, и они не хотят ограничивать разработчиков платформой, чтобы не быть всегда вторыми за тем же RoR.
Дело даже не в self-хостинге, а в возможности организовать адекватный хостинг на любом веб-сервере. Теперь для разработчиков веб-серверов есть спецификация, согласно которой можно написать модуль для существующего веб-сервера или даже специализированный веб-сервер, с помощью которого можно захостить любое owin-совместимое приложение. Katana это и есть один из таких хостингов. Вот вариант работы с NGINX по FastCGI: https://iobservable.net/blog/2013/08/01/owin-and-n...
> И Katana как-то помогает мне это решить, избавившись от System.Web
коротко - позволяет добиться модульности. Видите ли, MS сейчас активно работает над новыми подходами по развертыванию .net-приложений, в частности над .net core и философией "All is a NuGet package", что будет означать возможность использования РАЗЛИЧНЫХ версией asp.net с различными запущенными на хосте приложениями и возможность устанавливать нужные версии asp.net-сборок как nuget-зависимости, а не как раньше - в составе монолитного .net framework. Так что в рамках такого подхода необходимость в модульном веб-окружении достаточно очевидна.
> 2й пункт просто уничтожает производительность
ну уж если вы и так ловите все пакеты, тогда делайте GetTcpTable когда там ожидается что-то новое. Например, если прилетает пакет закрытия соединения, то тогда имеет смысл заново получить таблицу (ну или например если открывается новое соединение). А постоянно делать это какой смысл? Я думаю нужно все случаи аккуратно рассмотреть и перезагружать по необходимости, а не на каждый пакет конечно же.
Anchor00, я согласен с вами, что такая операция по крайней мере выглядит дорогой. Правда я не уверен, что она будет сильно дешевле в реляционной модели (т.е. если бы цвет был обычной колонкой в таблице). В больших БД с классическим хранением записей друг за другом операции добавления колонок могут занимать довольно приличное время (column-store базы не в счет). Во-вторых, десериализация, о которой вы говорите - вещь необходимая только в случае, если именно вы, на уровне приложения, добавляете/изменяете в каждом документе (товаре) атрибут Цвет. Если же вы попросите сделать это вашу СУБД, она, вероятно, справится с этим лучше. Например, предположу, что MongoDB не будет десериализовывать документы из BSON-а (bsonspec.org), в котором она их хранит, в JSON, она добавит атрибут так, как ей это удобно, с минимальными издержками. Аналогично и с XML-документами. Вероятно это будет медленнее, чем если бы у нас сразу была колонка Цвет, но это закономерная плата за гибкость и отсутствие схемы. Вывод из сказанного: прежде всего нужно максимально пользоваться возможностями СУБД, в т.ч. языком запросов. Поддержка JSON и XML в том и заключается, что это для СУБД уже не просто строки, а таки данные с определенной структурой. Ну и конечно если Mysql или Postgres вам дают лишь доп. набор функций для работы с JSON и небольшие оптимизации по производительности, то документно-ориентированные СУБД будут поддерживать такие данные нативно, и где-то выигрывать в производительности (хотя должен сказать, что видел наборы тестов, утеверждающих что PostgreSQL не особо отстает от Монги в хранении json-документов, так что этот вопрос требует исследования).
System.ValueType кстати это вообще довольно специальная материя, не думайте о ней как об обычном классе вроде тех, что есть у вас в коде. Этот тип по особому трактуется как компилятором, так и CLR, так что начните с понимания механизма упаковки)
nevro: https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx
> The concept of boxing and unboxing underlies the C# unified view of the type system in which a value of any type can be treated as an object.
Вот тут как раз об этом. С помощью этого механизма вам создают видимость (!) того, что абсолютно любое значение в языке - это object (is-a object).
nevro: попробуйте почитать статью, ссылка на которую есть в моем ответе. Если не поймете - отложите, прочтете позже, когда разберетесь с основами. Еще раз отмечу, что "наследование" значимых типов от класса object - по сути своей ненастоящее, это не то же самое, что наследование ссылочных типов. Когда мы говорим, что значимый тип наследуется от object, то нас это интересует с точки зрения установления отношения is-a ("является"). С точки зрения системы типов, это значит, что значения типа int можно подставить туда, куда передается значение типа object. С точки зрения полиморфизма, мы имеем возможность переопределять методы object-а. Однако и то, и другое достигается специальным средством платформы, которое называется boxing. Это специальная процедура "упаковки" значения значимого типа (неважно, int, double или вашего struct-а) в контейнер, обладающий свойствами значения ссылочного типа (и располагающийся в текущей реализации на куче). Важно, что эта процедура скрывается системой типов языка C# и для вас это будет просто приведение типа от int к object и обратно. Однако, это далеко не то же самое, что приведение от класса к object и обратно. Вы можете скомпилировать код с обеими преобразованиям и посмотреть на результирующий IL - и увидите разницу. Таким образом, можно грубо сказать, что значимый тип проявляет свойства ссылочного лишь тогда, когда этого от него хотят. Как только вы преобразуете свою структуру (вполне возможно, хранящуюся на стеке) к object, для вас автоматически создается контейнер и вам дают ссылку на него, и теперь ваша структурка уже как бы значение ссылочного типа (кстати, этот контейнер еще нужен и для того, чтобы можно было полиморфно вызывать переопределенные в структуре методы object-а). Поэтому это "наследование" и возможно. Помните, что наследование на уровне языка - это прежде всего is-a, и не особо важно, как это достигается.
Роман на всякий случай :) blogs.msdn.com/b/ericlippert/archive/2010/09/30/th...
> there is no language requirement that a data structure called "the stack" be used to store locals of value type
Я вот больше об этом. Много людей не понимает, что есть вопрос модели, а что - вопрос реализации.
nevro да, вот это как раз таки гарантируется спецификацией языка. Что у вас за книга, кстати? Это очень важные базовые вещи, если они не раскрываются в ней, возьмите другую. Или если книги еще никакой нет, то найдите. MSDN для изучения языка и платформы с нуля плохо подходит.
> подводные камни в производительности, или с ошибками в работе кода
да, нюансы разумеется есть, на то и разные "виды" (не знаю нормального термина) типов данных. Это все равно что в плюсах работать с T* или просто с T. Почитайте хорошую книгу, если что-то непонятно - спрашивайте.
jackroll я имею в виду уточнение понятия "фреймворк". Вам сложно было найти что-то, потому что вы искали фреймворк, а не отдельные компоненты, которые в него входят. Собственно, Mono пока единственная "полная" замена .Net Framework ("под ключ"), но с приходом docs.asp.net/en/latest/dnx/overview.html многое может измениться. В любом случае, Mono по-максимуму пытается построить совместимую реализацию, чтобы все приложения, работающие под .net fw, работали и под Mono. Поэтому вопрос плавно перетекает в следующие: 1) есть ли что-то еще кроме Mono, МАКСИМАЛЬНО совместимое с майкрософтовским дотнетом? 2) нужен ли нам полностью другой самостоятельный фреймворк, имеющий другую библиотеку классов? В чем он тогда будет совместим с майкрософтовским, кроме стандарта языка C#?
Вам какой аспект непонятен?
Олег если серьезно, то нормальная платформа, изначально ее репутация была, безусловно, испорчена привязкой к винде, но сейчас они исправляют это всеми силами (ибо начали зарабатывать на услугах, а не на платформе). Ни сам дотнет, ни C# в частности никакой привязки к Win не имеют. Скоро выходит новая платформа (новый asp.net, новый рантайм - DNX), и MS активно работает с Mono над слиянием реализаций CLR, библиотеки классов и прочего. Новый asp.net будет работать на линукс и Mac by design, а не через костыли.
Это не "тот же" system.web, что и в ранних версиях. В том смысле, что в новом asp.net этот system.web будет таким же опциональным, как и многие другие компоненты. Возможно стоит поискать минималистичный туториал. Или даже лучше туториал с других фреймворком, например с Нэнси: https://github.com/NancyFx/Nancy/wiki/Hosting-nanc... - здесь system.web уже не подключают, т.к. он НЕ НУЖЕН - мы вообще не используем ASP.Net. Ранее без ASP.Net обойтись можно было, только если самому реализовать еще и веб-сервер, ну или какой-нибудь fastcgi, и принимать входящие сетевые подключения. С OWIN можно использовать любой совместимый веб-сервер (IIS, self-hosting, как вы уже правильно заметили) с любым OWIN-приложением. Помимо того, что можно выбрать любой фреймворк, есть еще возможность добавлять так называемые middleware, через которые будет проходить http-запрос перед тем как попасть в основное приложение.
> В каких практических ситуациях необходимо оторваться от IIS?
Ну не знаю как у вас, а мне например неудобно арендовать сервер с виндой только ради IIS. PostgreSQL крутится на линухе, монга тоже, Mono сам по себе запускается нелохо, а вот для asp.net нужен бубен. Сейчас это стало неудобно даже для MS, т.к. теперь их важный доход - это Ажура, и они не хотят ограничивать разработчиков платформой, чтобы не быть всегда вторыми за тем же RoR.
Дело даже не в self-хостинге, а в возможности организовать адекватный хостинг на любом веб-сервере. Теперь для разработчиков веб-серверов есть спецификация, согласно которой можно написать модуль для существующего веб-сервера или даже специализированный веб-сервер, с помощью которого можно захостить любое owin-совместимое приложение. Katana это и есть один из таких хостингов. Вот вариант работы с NGINX по FastCGI: https://iobservable.net/blog/2013/08/01/owin-and-n...
> И Katana как-то помогает мне это решить, избавившись от System.Web
коротко - позволяет добиться модульности. Видите ли, MS сейчас активно работает над новыми подходами по развертыванию .net-приложений, в частности над .net core и философией "All is a NuGet package", что будет означать возможность использования РАЗЛИЧНЫХ версией asp.net с различными запущенными на хосте приложениями и возможность устанавливать нужные версии asp.net-сборок как nuget-зависимости, а не как раньше - в составе монолитного .net framework. Так что в рамках такого подхода необходимость в модульном веб-окружении достаточно очевидна.