Павел Никитин все-таки я предлагаю сначала конфигурацию игрового сервера глянуть. Если там ip-шник прописан, в этом и может заключаться проблема, его нужно сменить. Все-таки дело в виндовой машине, раз порты не открываются на прослушку. А, еще проверьте, не занят ли нужный порт кем-то еще. Это маловероятно, но чем черт не шутит.
Также, ВОЗМОЖНО, дедик пытается слушать на IPv6-интерфейсе, который почему-то выбирает по-умолчанию, такое тоже бывает. И поэтому вы не видите прослушиваемых TCP-портов. Возможно стоит прописать конкретный IP, если это еще не было сделано.
Николай Третьяков понимаю, что не хочет держать инфраструктуру, но почему бы, например, не кинуть VPN в локалку заказчика? Любой опытный админ поднимет IPsec и настроит файрволл на пропуск только необходимого трафика к SQL Server и обратно. Админ SQL Server пусть создаст пользователей с нужными правами, как и посоветовал Дмитрий Ковальский .
Кстати, насчет WebAPI - если не хотите держать инфраструктуру всего сайта, почему б не предоставить небольшой веб-сервис? Это будет даже лучше - всякие системы бронирования билетов так и делают. Какой-нибудь aviasales.ru хостится на своих серверах, и уж точно не имеет прямого доступа к SQL-базам авиаперевозчиков. Все данные по билетам прилетают от веб-сервисов, они для этого и были придуманы. Киньте также VPN к заказчику, поднимите у него сервис (если нужна производительность, можно даже не WebAPI взять, а WCF поверх net.tcp или Protocol Buffers) и дергайте его с сайта. Причем, именно ASP.NET приложение будет дергать этот сервис, а не внешний клиент из интернета, чтобы заказчик меньше переживал о безопасности данных.
Ultraice ну в целом и я бы так поступил. Подводные камни будут, если привязка будет записываться, и её нужно будет обновлять при обновлении правил. Ну т.е. не забыть обновить все нужные привязки, например, если обновлено правило в категории, у которой есть дочерние категории. Плюс, нужно решить, нужна ли вам избыточность в иерархии привязок, т.е. нужно ли привязывать товар к родительской категории, если он уже привязан к одной из её дочерних категорий. По идее, такая привязка излишняя, но возможно она ускорит вам выполнение запросов по родительской категории, т.к. не придётся собирать привязки со всего дерева дочерних категорий.
В общем, т.к. привязка товара и категории - информация по своей природе производная, и значит, избыточная для хранения, вы получаете стандартные бонусы и подводные камни при хранении избыточной информации - необходимость поддерживать её в актуальном и непротиворечивом состоянии.
> с информацией, которая вам неприятна и возможно не нужна - но на любой работе это будет встречаться
Золотые слова. Видел немало толковых людей, которые не смогли побороть именно это.
Toxygen почему вы считаете, что мой вариант вам не подходит? Событие изменения выбранного элемента логичнее отслеживать в TreeView, а не в TreeViewItem. А OnSelectedItemChanged - это как раз то, что вам нужно для "поведения, встроенного в контрол".
Антон Иванов собственно, а какое решение вы хотите? Вы хотите, чтобы поля не нужно было дублировать, но не хотите выносить что-либо в отдельную сущность. Создаётся впечатление, что вы уже ждёте чего-то конкретного. Озвучьте тогда)
Антон Иванов почему вы тогда считаете, что это костыль?
Я считаю, что это костыль, потому что если вам что-то нужно будет добавить именно в request, но не в order, вы не сможете это сделать. Запрос имеет право иметь дополнительную информацию, которая не должна быть в уже созданном order. OrderInfo вы создаете специально для того, чтобы там были именно общие поля.
Нужно думать не только о том, что по факту получается ПРЯМО СЕЙЧАС, но и подумать, как ваши сущности смогут изменяться в будущем. Тогда сразу станут видны некоторые неестественные зависимости.
Антон Иванов отличие будет в том, что у вас Order не будет наследоваться от OrderRequest, что есть, как вы сказали, костыль. Так вы сможете и в Order, и в OrderRequest добавить по необходимости свои поля, и у вас не будет так, что всё без исключения содержимое OrderRequest всегда попадает в Order.
Александр Николаевич можно, но об этом нужно подумать заранее. Т.е. вам нужно будет рисовать мозг монолитом, а затем, после определенного увеличения, переходить к рисованию нейронов. Хотя всё равно мало вижу в этом смысла, т.е. это будет все весьма схематично.
Александр Николаевич
> видеть в жизни то есть мозг состоящий из отдельных нейронов
Об этом и речь, что в жизни вы не видите отдельных нейронов, когда смотрите на мозг, или даже если не смотрите, а просто представляете себе. Нейронов огромное количество, вам желательно определиться, вы хотите картинку как в атласе, или картинку с "увеличением" до масштаба отдельных нейронов (см. ссылку выше)
Также, ВОЗМОЖНО, дедик пытается слушать на IPv6-интерфейсе, который почему-то выбирает по-умолчанию, такое тоже бывает. И поэтому вы не видите прослушиваемых TCP-портов. Возможно стоит прописать конкретный IP, если это еще не было сделано.