Антон Иванов отличие будет в том, что у вас Order не будет наследоваться от OrderRequest, что есть, как вы сказали, костыль. Так вы сможете и в Order, и в OrderRequest добавить по необходимости свои поля, и у вас не будет так, что всё без исключения содержимое OrderRequest всегда попадает в Order.
Александр Николаевич можно, но об этом нужно подумать заранее. Т.е. вам нужно будет рисовать мозг монолитом, а затем, после определенного увеличения, переходить к рисованию нейронов. Хотя всё равно мало вижу в этом смысла, т.е. это будет все весьма схематично.
Александр Николаевич
> видеть в жизни то есть мозг состоящий из отдельных нейронов
Об этом и речь, что в жизни вы не видите отдельных нейронов, когда смотрите на мозг, или даже если не смотрите, а просто представляете себе. Нейронов огромное количество, вам желательно определиться, вы хотите картинку как в атласе, или картинку с "увеличением" до масштаба отдельных нейронов (см. ссылку выше)
beduin01 вы пытаетесь выполнить одну update-транзакцию параллельно с другой. С FB не работал, не знаю насколько гранулярны там блокировки, возможно что блокируется вся таблица. Что с этим делать, вам лучше почитать в доках по Firebird (я имею в виду, как правильно осуществлять параллельные транзакции). Но сначала сделайте Dispose транзакции - коммита, возможно, только закрепляет транзакцию, но не снимает блокировки, или, например, автоматом начинает новую транзакцию, из-за чего у вас эта новая транзакция остается открытой и держит таблицу/запись в базе заблокированной. Всему, что реализует IDisposable, в том числе через базовые классы, нужно делать Dispose. Чтобы не забыть это делать, и дополнительно структурировать код, ознакомьтесь с оператором using: https://msdn.microsoft.com/ru-ru/library/yh598w02.aspx
Дмитрий ну на рассылки подпишитесь. Конфы смотрите, Build тот же. Хабр в конце-концов. Мне вот этого всего с головой хватает, чтобы "следить". Или вам конкретно реальные примеры в реальных компаниях?
apasen я под "бэком" и имею в виду API. И именно этот случай я и рассматриваю.
Я так и не понял в чем ваша проблема/задача. Что или кого вы собираетесь _авторизовать_ - юзера или ваш код? Что или кто и какой токен будет уводить? Кто есть злоумышленник, кто есть жертва и что есть предмет воровства, можете четко объяснить?
apasen не вполне понятно, почему стоит такая цель. Хорошее REST API - такое, к которому что из официального клиента (в том числе из веб-приложения), что по curl-у - одинаково и по сути дело конкретного пользователя. У вас выходит, что вы имеете какую-то доверенную логику в КЛИЕНТЕ, и вам нужно быть уверенным, что именно ваш клиент отправил запрос. Т.е. вам надо авторизовать клиентский КОД, а не пользователя. Вопрос - зачем вам так надо? Нет возможности эту доверенную логику перенести на сервер?
Александр Александров чтобы вас не запутать, предупреждаю, что под RPC я имею в виду не конкретную реализацию, а архитектурный подход в целом, основанный на правиле "мало сущностей, много действий" в отличие от REST, базирующемся на "много сущностей, мало действий".
Александр Александров но вообще да, еще раз подумайте над вопросом игрового состояния. Тут дело не в высокой нагруженности. REST это паттерн, который удобно применять, когда состояния (т.е. некоей игровой сессии) в общем-то нет, и от этого паттерна можно получить преимущества. Когда состояние есть, и нет смысла от него "убегать", попытка натянуть задачу на REST-архитектуру только потратит ваше время. RPC-подход будет гораздо более логичным выбором.
Александр Александров да сейчас его можно на чём угодно написать. Хотите попробовать C# в этой роли - посмотрите ASP.NET WebAPI или даже Nancy ( nancyfx.org ). Хотите попробовать JS - берите Ноду ( https://nodejs.org/en/ ). Язык подойдет любой из упомянутых вами, разве что не стоит брать тяжелый фреймворк с MVC, если нужен только веб-сервис, а не классический сайт с генерацией HTML-контента. Выберите сначала язык, с которым хотите работать на сервере, а потом сами поищите или задайте вопрос о выборе фреймворка для веб-сервиса на конкретном языке, если вам нужно будет больше информации.
Роман да, и правда, там пока только Redis. Ну EF 7 еще в 2014 году был заявлен (потом правда переименован в EF Core), так что с учётом стандартного правила "технологию лучше изучать, пока она в бете или RC", можно уже начить знакомиться)
Хотя я, честно говоря, перестал работать с EF уже давно, полностью ушел на NHibernate.
korsamc
> а остальные две вызвали у меня сложность
с такой информацией о проблеме мы не сможем вам помочь. Неужели вы не понимаете, что вашу проблему нужно описывать подробно? На вас компилятор ругался, или вы не смогли найти документацию?
