Ниче он не тролит, Твиттер расчитан на конкреный юзкейс. Зайдите щас на Г+, там нема ограничения на длину сообщения и чтобы прочесть сообщения от 40 юзеров, надо потратить ощутимое время, помойка получается. Сравните с 300 юзерами в твиттере, где чутли не все можно окинуть одним взглядом. А вот если твит заинтерисовал, то тогда уже клацам на линку и топаем смотреть/читать больше.
browserid.org это временная замена реализации в браузере, может еще подрабатывать как секондари, этот секондари вы можете поднять и в локалке. Как тока появятся дургие провайдеры и реализация в браузерах (под ФФ сокро будет аддин) этот сайт вообще станет необязательным.
У нас на одну сущность/аспект/фитчер (это может быть несколько класов) заводится целая папка, а и одна тест фикстура на каждый сценрий. Поэтому читаем мы обыно по названиям файлов ;).
Большая часть Should фремвокров расширяема (один и тот же принцип, екстеншен методы, раширения тож переносятся без проблем). Поэтому обычно проще дописать того чего не хватает.
Этих Should DSLей развелось што капец. Если в Нюгет поискать, то наверное свободно можно больше десятока найти. Отличия обычно тока в каком месте стоит точка, и знании английского у разработчиков.
Я бы рекомендовал юзать что-то уже готовое, чем велосипед (собсно я так и делаю, хотя у меня самого есть такой фремвфорк, правда для F# :).
Просто интересно, мы просто даже обкатывать не рискнули, про него стока слухов ходит (да и не тока слухов, на прошлом PDC вторую ноду на глазах у всех подключить не смогли). Еще более будет интересно узнать результаты использования в продакшене.
1) Потдерижвает вложенные, я даже проверять не буду.
2) Родной .svc, может быть асинхронным, метод должен вернуть IAsyncResult
3) Конвеншен чтобы убрать атрибуты пишется на раз два три. Причем ладно там WCF, тот же ASP.NET MVC все это может (это мой старючий пост).
4) У вашего «очень удобно» даж коментировать не буду, вы че реально считате что в локальном коде неззя найти интересной инфы? Вас даже задосить будет на раз два три.
5) «видео и дозагрузка файлов» без понятия заимплеменчено ли. Быстрее всего нет. Но что-то вы многовато хотити от application server.
Такс, ради вас проверил можно ли возвращать Stream. Можно. Никаких вообще проблем:
public Stream GetImage(string filePath){
return File.OpenRead(filePath);
}
Забыл охватить «сложные Json структуры для него не «съедобны»», вопервых, оно все что надо хавает. Даже если несхавает, подрубить JSON.NET туда, это приблизительно 8 строк кода ;), а можно просто подрубить.
1) У меня нет Web.config-а, потому что он не нужен.
2) WCF может вернуть HttpResponseMessage
public HttResponseMessage GetImage(string filePath){
return new HttResponseMessage{Content = new StreamContent(File.Read(filePath))}
}
Писал по памяти, но суть такова. Причем при желании в 10ть строк можно написать форматтер чтобы возвращало стрим. На самом то деле я не уверен что там Стрим неззя возвращать, это я так сказать вам верю.
3) Конешно же пересобрать. Я же нехочу чтобы кто-то мог свободно вызвать CurrentConnections(«MyaConnection») и получить стоку соединения с БД ;).
4) Что-то не понял о каких ограничениях речь. Хотя WCF Web API собсно имплементит и IHttpAsyncHandler и IHttpHandler
Я уже попробовал, код сразу же над вашим коментраием. Подставьте там нужные методы, а клиенты такими и остантуся, сервис вернет самый обычный JSON. Урлы будут ввиде localhost/Commands/xxxx, под хххх будет то как UriTemplate.
Более того, оно еще и принимать JSON может(уже обьектом), и формат выбирает не через урл (разве что для девелоперский целей), а правильно чере Accrpt хеадер.
Для затравки, это код для регисрации. RouteTable.Routes.MapServiceRoute("Commands");
А это код сервиса. [ServiceContract]
public class CommandsService
{
[WebGet(UriTemplate = "")]
public CommandDef Get()
{
return new CommandDef{};
}
}
... Странно да?
Я знаю что такое ashx. С роутингом, одна строка кода и без всяких файлов готов сервис. С нормальными урлами. На написание этой статьи ушло больше времени че на «играться» с WCF и роутингом.
Непонял в чем фишка, уже ж есть WCF Web API. Там все заимплпменченно, и УРЛЫ нормальные (service.ashx < — что это за хрень?), так как там используется System.Web.Routing.
Короче, велосипед который в теории был бы оправдан лет пять тому назад. Минусявка от меня, а то позору за платформу не обрешся.
Некоторые френдленты хотябы борятся с этим всем. Вон фейсбук: 1) сворачивает в одно сообщение если разшарили 300 человек, 2) фильтрует всякую фигню от неактивных контактов (тех с которыми вы не общаетесь) 3) показывает тока главное. Короче они хоть как-то пытаются бороться с этой проблемой.
В OData оно для JSON кстати заимплеменчено как __metadata поле, а там уже ест uri представляющий ресурс.
Пользовался nuget.org/List/Packages/SharpTestsEx (когда он еще был NUnitEx)
Щас по большей части пользуюсь nuget.org/List/Packages/ShouldFluent или nuget.org/List/Packages/FluentAssertions
Разница нулевая, пользоваться начинаю обычно тем что раньше попадется в Nuget.
Я бы рекомендовал юзать что-то уже готовое, чем велосипед (собсно я так и делаю, хотя у меня самого есть такой фремвфорк, правда для F# :).
2) Родной .svc, может быть асинхронным, метод должен вернуть IAsyncResult
3) Конвеншен чтобы убрать атрибуты пишется на раз два три. Причем ладно там WCF, тот же ASP.NET MVC все это может (это мой старючий пост).
4) У вашего «очень удобно» даж коментировать не буду, вы че реально считате что в локальном коде неззя найти интересной инфы? Вас даже задосить будет на раз два три.
5) «видео и дозагрузка файлов» без понятия заимплеменчено ли. Быстрее всего нет. Но что-то вы многовато хотити от application server.
public Stream GetImage(string filePath){
return File.OpenRead(filePath);
}
Забыл охватить «сложные Json структуры для него не «съедобны»», вопервых, оно все что надо хавает. Даже если несхавает, подрубить JSON.NET туда, это приблизительно 8 строк кода ;), а можно просто подрубить.
2) WCF может вернуть HttpResponseMessage
public HttResponseMessage GetImage(string filePath){return new HttResponseMessage{Content = new StreamContent(File.Read(filePath))}
}
Писал по памяти, но суть такова. Причем при желании в 10ть строк можно написать форматтер чтобы возвращало стрим. На самом то деле я не уверен что там Стрим неззя возвращать, это я так сказать вам верю.
3) Конешно же пересобрать. Я же нехочу чтобы кто-то мог свободно вызвать CurrentConnections(«MyaConnection») и получить стоку соединения с БД ;).
4) Что-то не понял о каких ограничениях речь. Хотя WCF Web API собсно имплементит и IHttpAsyncHandler и IHttpHandler
Более того, оно еще и принимать JSON может(уже обьектом), и формат выбирает не через урл (разве что для девелоперский целей), а правильно чере Accrpt хеадер.
RouteTable.Routes.MapServiceRoute("Commands");
А это код сервиса.
[ServiceContract]public class CommandsService
{
[WebGet(UriTemplate = "")]
public CommandDef Get()
{
return new CommandDef{};
}
}
... Странно да?
Короче, велосипед который в теории был бы оправдан лет пять тому назад. Минусявка от меня, а то позору за платформу не обрешся.