В теории вам не нужны дополнительные сущности для хранение — вы можете использовать доменные + EF mapping (ведь EF'у не обязательно нужны всякие атрибуты и т.п., но есть небольшие ограничения над сущностями (типа обязательного paramterless конструктора) что опять же чуть-чуть подтекающая абстракция ;-)
WinForms намного менее требователен к железу, а скорость разработки не сильно ниже (да, там нет MVVM, но и MVP не плох). Ну и Qt+qml как вариант (красиво и без тормозов)
несколько странно видеть требование «запуск даже на калькуляторе» и тормозной WPF (3 draw calls чтобы отрисовать эллипс) с монструозной Prism'ой в одном предложении.
Да, то что нужно. Странно что не из коробки. Ещё бы two-way binding и было бы прекрасно. Сейчас нафигачил сложную форму и смотрю профайлером насколько это тормознуто всё.
Это немного другая вьюха, не от MVP/C, а от MVVM, ей можно. в MVVM ViewModel не сильно волнуется о том, в каком именно виде вьюха отразит день рождения. Вообще очень клево, давно это ждал. После опыта с Windows и MVVM разработка под Android приносила некоторый зуд и неудобство, спасибо Butterknife хоть как-то уменьшал этот зуд. Теперь заживём :-).
Ну тут надо надеятся, что либо котлин, либо свифт покроют вторую платформу — вроде вполне современные языки. Так что вся надежда на Jetbrains (kotlin/appcode). или Xamarin.
Да, протекает. Но не так уж и легко — в EF (и даже в дотнетовской реализации Hibernate) всё нужное интерпретируемо в SQL даже если вы в фильтре вызовете contains на какой-нибудь локальный лист. Давно не сталкивался с ошибками того, что я что-то не то сделал в лямбдах в linq. Раньше в спорах java vs C# в ход шел козырь кроссплатформенность. Сейчас он как-то стал неактуален с xamarin. И пошёл новый козырь: у нас фичи продумываются столетиями и всё идеально, а у вас бардак :-).
2) — var в C# не ослабляет типизацию. это автовычисление типа по выражению справа.
4) да, сам подумал так, но тогда могу усложнить пример — надо выполнить 3 разных запроса один за одним обновляя текст на UI:
немножко добавлю холивара про фичи языка — полгода назад стал активно писать проекты под Android на java (фактически перешел на нее с C#) и есть пару веще с которыми мне сейчас тяжело мириться:
1) цирк с примитивными типами long--Long с невозможностью юзать первые в генериках (уж молчу о том, что нельзя писать свои кастомные Value Types)
2) отсутсвие var (или как в плюсах — auto). хоть за сниппет .var спасибо IDE. но все равно не то. сравните:
FooFactoryFactory foo = new FooFactoryFactory();
vs:
var foo = new FooFactoryFactory();
3) лямбды и Stream — очень рад что это появилось в яве, хоть до C# LINQ не дотягивает отсутсвием возможности разбора дерева выражения. Ну и через костыли в принципе подключаемо к андроиду.
4) ну и конечно же async/await
представьте что вам нужно послать ассинхронный реквест и по приходу ответа обновить текст на UI:
android java:
client.sendRequest(request, new ResponseCallback() {
@Override
public void onResult(Object object) {
currentActivity.runOnUiThread(new Runnable() {
@Override
public void run() {
currentActivity.title.setText("done!");
}
});
}
});
android C#:
var responseObj = await SendRequest(request);
//runOnUiThread не нужен т.к. await вернет первоначальный контекст
currentActivity.title.Text = "done"
Но это сравнивая решения в лоб без библиотек типа robospice, javaRX (за которую большое спасибо)
PS: не течёт. немножко подтекает ;-)
который бы при выполнении сконвертился бы в SQL
и вернул объекты из бд. Но в целом согласен — фичи надо вводить с умом
если мы не приводим к базовому/интерфейсу — эта копипаста не нужна и должна быть заменена на
4) да, сам подумал так, но тогда могу усложнить пример — надо выполнить 3 разных запроса один за одним обновляя текст на UI:
vs:
писал в блокноте поэтому уверен что в java напутал в конце со скобками ибо нечитаемо.
зы: пробовал. на котлин вся надежда.
1) цирк с примитивными типами long--Long с невозможностью юзать первые в генериках (уж молчу о том, что нельзя писать свои кастомные Value Types)
2) отсутсвие var (или как в плюсах — auto). хоть за сниппет .var спасибо IDE. но все равно не то. сравните:
3) лямбды и Stream — очень рад что это появилось в яве, хоть до C# LINQ не дотягивает отсутсвием возможности разбора дерева выражения. Ну и через костыли в принципе подключаемо к андроиду.
4) ну и конечно же async/await
представьте что вам нужно послать ассинхронный реквест и по приходу ответа обновить текст на UI:
android java:
android C#:
Но это сравнивая решения в лоб без библиотек типа robospice, javaRX (за которую большое спасибо)