Wpf: привязка данных из объекта

#c_sharp #framework #wpf #net #binding

Есть отдельный класс Piple с кучей данных о человеке, я создаю объект этого класса
в MainWinow. В главном окне приложения у меня множество различных texbox, для этого
объекта (имя, фамилия и т.д.). Можно ли как-то использую Binding, сделать так, что
бы при изменение объекта изменялись бы данные в соответствующих textbox, и наоборот,
при изменение в textbox, изменялись бы соответствующие поля в Piple?

Вот код  класса Piple:

namespace WpfApplication4
{
    public class Piple 
     {          
        public string name;
        public string name2;
        public Piple()
        {   
            name="Иван";
            name2="Иванов";
        }    
    }
}


Код главнного класса C#:  

  namespace WpfApplication4
  {
        /// 

        /// Логика взаимодействия для MainWindow.xaml
        /// 
        public partial class MainWindow : Window
        {
            Piple chel = new Piple();
            public MainWindow()
            {
                InitializeComponent();
                this.DataContext = this;                    
            }
         }
}


Код окна на XAML


    

        


        

    



Нужно соответственно привязать данныйе из chel.name и chel.name2 к соответствующим
textbox. Подскажите можно ли это сделать с помощью Binding?
    

Ответы

Ответ 1

Привязка к полям класса в WPF невозможна, Вам нужны хотя бы свойства (property).
Чтобы при изменении свойств класса новые значения отображались в контроле, нужно
чтобы класс был наследником интерфейса INotifyPropertyChanged
Вы сами биндинги-то не прописали у TextBox'ов.

Все это должно выглядеть как-то так:
    public class People : INotifyPropertyChanged // Наследуемся от нужного интерфеса
    {
        // Ваши поля 
        private string name, name2;

        public event PropertyChangedEventHandler PropertyChanged; // Событие, которое
нужно вызывать при изменении

        // Для удобства обернем событие в метод с единственным параметром - имя изменяемого
свойства
        public void RaisePropertyChanged(string propertyName)
        {
            // Если кто-то на него подписан, то вызывем его
            if (PropertyChanged != null)
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }

        // А тут будут свойства, в которые мы обернем поля
        public string Name
        {
            get { return name; }
            set
            {
                // Устанавливаем новое значение
                name = value;
                // Сообщаем всем, кто подписан на событие PropertyChanged, что поле
изменилось Name
                RaisePropertyChanged("Name");
            }
        }

        public string Name2
        {
            get { return name2; }
            set
            {
                // Устанавливаем новое значение
                name2 = value;
                // Сообщаем всем, кто подписан на событие PropertyChanged, что поле
изменилось Name2
                RaisePropertyChanged("Name2");
            }
        }
    }

В коде контрола создаем экземпляр класса и прописываем DataContext (на самом деле
DataContext можно прописать и в разметке контрола):
        public MainWindow()
        {
            // Создаем экземпляр нашего класса
            P = new People(){Name = "Ololosha", Name2 = "Trololosha"};
            InitializeComponent();
            // Устанавливаем как контекст данных
            DataContext = P;
        }

А в разметке контрола прописываем TextBox'ы:



Вот теперь оно будет работать так, как вы хотите.
Еще наверное надо упоминуть о таком свойстве биндинга как UpdateSourceTrigger. Оно
описывает когда надо изменить источник. По умолчанию у TextBox'а стоит значение LostFocus,
т.е. изменение произойдет только когда TextBox потеряет фокус. Если Вы хотите, чтобы
изменения происходили сразу же, то Вам нужно UpdateSourceTrigger установить в PropertyChanged:


Я бы Вам посоветовал найти хорошую книжку по WPF. Вот тут есть довольно неплохой
сайт о WPF (и не только о нем), по крайней мере мне в свое время он очень помог

Перенос крупного PHP приложения на Python [закрыт]

#python #framework #php #flask #django

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 3 года назад.
                                                                                
           
                
        
Всем привет!
Требуется перенести крупный (с очень сложной структурой) веб-проект на Python-платформу.
Приложение представляет из себя что-то вроде социальной сети или сообщества для корпоративного
использования.
База данных меняться не будет (MySQL), а её структура и подавно. Поэтому будущая
система должна писаться с оглядкой на уже существующие данные и базу.
Система должна быть очень гибкой и удобной для всевозможных изменений.
Изначально планировали смотреть на Django. Но немного познакомившись - смутились:

Структура пользователей (и не только) в базе должна строго ложиться на уже существующую.
Структура Django нам не подходит. Или нужно переписывать стандартную структуру и исправлять
это (что мы так понимаем делать крайне не рекомендуется).
Тоже самое касается прав доступа, логов, отчасти сессий (не принципиально) и прочих
плюшек которые идут в джанго "из коробки"
Админка "из коробки" не подходит по всевозможным причинам. Начиная с дизайна-юзабилити
и заканчивая структурой. Из-за этого мы плачем по ночам...
ORM хорош, но есть места где придётся им пренебречь

Отсюда выходит, что большинство тех возможностей которые имеет (или может в перспективе
иметь с установкой подходящих плагинов или расширений) Django - для нас не актуальны. 
Поэтому вопрос таков: на чем стоит разрабатывать приложение?
В качестве вариантов рассматривали Flask и Pylons, но по ним информации (а тем более
кадров) намного меньше. Поэтому будем рады замечаниям на этот счет. 
Подтвердите, опровергните наши размышления либо предложите какой-то свой вариант
решения проблемы. Очень будем признательны за развернутый ответ.
Возможно мы где-то пропустили важные моменты для понимая сути проблемы - пишите,
обязательно дополним.    

Ответы

Ответ 1

я выскажу свое мнение:
1) Для крупных проектов используется JAVA либо C#
2) Некоторые используют PYTHON (типа яндекса) кто-то и PHP
3) PHP - крутится в этом направлении (сайтов и соц.сетей)
4) "Убогость PHP" ну никак не оправдано, это довольно быстрый язык и на нем стоит
куча сайтов (до недавнего времени ВК стоял на ПХП и проблем не было)
5) ПХП обновляется динамично что дает через некоторое время оптимизацию тех функцию
которые на сегодняшний момент работают не так глатко.
6) раз у вас там мега-сеть, легче купить вторую машину, которая будет брать часть
нагрузки, чем все переписывать.
7) поддерживать ПХП (по мне так) легче.
8) Хотите быстродействие? берите вон KPHP


Ответ 2

Вставлю и я свои 5 копеек..
На Flask и Pylons у меня опыта нет, потому дам только контр-аргументы к вашим по Django:

Структуру пользователей можно переписать, если речь о большом проекте, то это не
самая сложная задача с которой придется столкнуться. Что такое фреймворк вообще? -
это среда, это набор инструментов. Никто не обязывает использовать все инструменты.
Если хоть чуть более половины инструментов представленных тем или иным фреймворком
вам подходит, то уже есть смысл его использовать. А идеально ни один универсальный
фреймворк под специфический проект не подойдет, имхо.
Систему прав доступа само собой надо делать под себя. Я как бы за три года ни разу
не видел, чтобы кто-то джанговской всерьез пользовался, ну разумеется за исключением
базовых опций (суперпользователь, статус персонала).
Ну опять, Django-админка она для удобства на этапе разработки или для полноценного
использования в небольших проектах, хотя ее можно кастомизировать достаточно глубоко,
и существует на эту тему некоторое количество сторонних пакетов. Но в вашем случае,
для корпоративной системы все равно свою писать нужно.
ORM потому и хорош, что удобен быстротой и простотой в несложных популярных случаях,
но никто не обещал, что он пригоден абсолютно везде, там где проще вам будет, то пишите
себе на здоровье raw-запросы.

ПС: Если ваша команда пока только будет начинать изучать новые инструменты и еще
нет выработанных привычек, то можно взять Flask ибо он слывет своей минималистичностью,
вы сами напишете к нему что нужно и не будет избыточности в вашем случае. Но если в
будущем надо будет набирать новых разработчиков, то мне кажется на Django найти специалиста
куда проще, чем на всякую экзотику.

Кросс доменная авторизация на yii2

#php #yii2 #framework

Всем привет!
Возникла такая проблема, нужно реализовать кросс доменную авторизацию.
Схема такая:
1. На первом домене(user.mysite.com) находится личный кабинет пользователя который
работает на yii2 и через который будет проходить авторизация.
2. На втором домене(mysite.com) находится интернет магазин на "самописном" движке
который должен работать с авторизированным пользователем. 
 
3. БД у них одна.
4. Лежат на одном сервере, в соседних каталогах.
5. должна быть реализована опция "запомнить меня"

Подскажите, можно ли это заставить работать? И как это лучше сделать?
    

Ответы

Ответ 1

В конфиге

'user' => [
    'identityClass' => 'common\models\User',
    'enableAutoLogin' => true,
    'identityCookie' => [
        'name' => '_identity',
        'httpOnly' => true,
        'domain' => '.' . DOMAIN,
    ],
],
'session' => [
    'cookieParams' => [
        'domain' => '.' . DOMAIN,
        'httpOnly' => true,
    ],
],


В index.php 

defined('DOMAIN') or define('DOMAIN', 'mysite.com');


Куки будут общими для домена и сабдоменов


Ответ 2

Надо чтобы на обоих доменах совпадали 


класс аутентификации, вероятно так и есть, если используются родные механизмы Yii;
домен, где сохраняется аутентификационная кука. в настройках сайта на под-домене
укажите родительский домен;
база с пользовательскими аккаунтами. вы сказали, что БД общая - ок.


На всякий случай скажу:
Не тестируйте это на домене localhost. Браузеры чудят с куками на доменах первого
уровня. Если надо испытать локально, заведите в hosts синоним для локалхоста, типа
localhost.com.
Обратите внимание в настройках на точку перед именем домена, это каноническая форма!

См.
http://yiiframework.ru/doc/cookbook/ru/install.cookie.subdomains
https://stackoverflow.com/questions/29378697/automagically-log-into-multiple-domains-in-yii2

Проблемы при настройке symfony 2.7 и 3.0 (проблема одна и та же)

#php #framework #symfony2 #symfony #symfony3

Проблемы при настройке symfony 2.7 и 3.0 (проблема одна и та же)


  Major problems have been detected and must be fixed before continuing:
  Change the permissions of either "app/cache/" or "var/cache/"
  directory so that the web server can write into it. Change the
  permissions of either "app/logs/" or "var/logs/" directory so that the
  web server can write into it.


Стандартные решения, естественно, попробовал из документации Symfony, глава Checking
Symfony Application Configuration and Setup.

Setting up Permissions:

Yuri@localhost /v/w/symfony.loc> sudo rm -rf var/cache/*
Yuri@localhost /v/w/symfony.loc> sudo rm -rf var/logs/*
Yuri@localhost /v/w/symfony.loc> sudo setfacl -R -m u:apache:rwX -m u:Yuri:rwX var/cache
var/logs
Yuri@localhost /v/w/symfony.loc> sudo setfacl -dR -m u:apache:rwX -m u:Yuri:rwX var/cache
var/logs
Yuri@localhost /v/w/symfony.loc> sudo service httpd restart
Redirecting to /bin/systemctl restart  httpd.service


Группа у web-server точно apache. Пруф

Yuri@localhost /v/w/symfony.loc> 
ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v
root | head -1 | cut -d\  -f1
apache
Yuri@localhost /v/w/symfony.loc>


Так же использовал крайние решение из главы Setting up Permissions:
подставил в начало файлов: (bin/console, web/app.php и web/app_dev.php) -> umask(0000)
в начало;

Yuri@localhost /v/w/symfony.loc> sudo service httpd restart
Redirecting to /bin/systemctl restart  httpd.service
Yuri@localhost /v/w/symfony.loc> service httpd status
Redirecting to /bin/systemctl status  httpd.service
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset:
disabled)
   Active: active (running) since Чт 2015-12-24 23:17:13 MSK; 11min ago
 Main PID: 9196 (httpd)
   Status: "Total requests: 8; Idle/Busy workers 100/0;Requests/sec: 0.0121; Bytes
served/sec:  51 B/sec"
   CGroup: /system.slice/httpd.service
           ├─9196 /usr/sbin/httpd -DFOREGROUND
           ├─9197 /usr/sbin/httpd -DFOREGROUND
           ├─9198 /usr/sbin/httpd -DFOREGROUND
           ├─9199 /usr/sbin/httpd -DFOREGROUND
           ├─9201 /usr/sbin/httpd -DFOREGROUND
           ├─9205 /usr/sbin/httpd -DFOREGROUND
           ├─9207 /usr/sbin/httpd -DFOREGROUND
           └─9354 /usr/sbin/httpd -DFOREGROUND

дек 24 23:17:13 localhost.localdomain systemd[1]: Starting The Apache HTTP...
дек 24 23:17:13 localhost.localdomain httpd[9196]: AH00548: NameVirtualHos...
дек 24 23:17:13 localhost.localdomain systemd[1]: Started The Apache HTTP ...
Hint: Some lines were ellipsized, use -l to show in full.
Yuri@localhost /v/w/symfony.loc> 


Nginx и php-fpm точно не включен 

Yuri@localhost /v/w/symfony.loc> sudo service php-fpm status
[sudo] пароль для Yuri: 
Redirecting to /bin/systemctl status  php-fpm.service
● php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset:
disabled)
   Active: inactive (dead)
Yuri@localhost /v/w/symfony.loc> sudo service nginx status
Redirecting to /bin/systemctl status  nginx.service
● nginx.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
Yuri@localhost /v/w/symfony.loc>


На просторах Ru&En-нета не нашел больше решений:(
Повторюсь, проблема на symfony 2.7 и 3.0 идентична. Пробовал на fedora 22 php5.6.15
и php7. Пробовал уже различные комбинации владельцев apache:Yuri, в том числе и на
создание новых файлов тоже выставлять - ничего не помогло.:(
Есть еще возможные варианты?
    

Ответы

Ответ 1

Если кому интересно, то проблема была в SELinux.
vi /etc/selinux/config или nano /etc/selinux/config
И перезагрузить комп sudo reboot


Ответ 2

я не парился и добавил алиас на composer который выполняется от www-data
sudo www-data -c 'composer app/console' вроде такого.

Не получается вызвать функции, которые лежат внутри функции

#javascript #jquery #framework

Решил для себя понять простой принцип работы jQuery и столкнулся с проблемой. При
попытке организации упрощенной версии библиотеки у меня не получается вызвать функции,
которые лежат внутри функции. Пример кода:

var jQ = function(el) {
   this.el = document.getElementById(el);
}

jQ.prototype.html = function(text){
  this.el.innerHTML = text;
  return this;
}

jQ.prototype.css = function(key, value){
  this.el.style[key] = value;
  return this;
}

// Использование 
jQ('bar').html('test');

    

Ответы

Ответ 1

function extend(Child, Parent) {
    var F = function() { }
    F.prototype = Parent.prototype
    Child.prototype = new F()
    Child.prototype.constructor = Child
    Child.superclass = Parent.prototype
}

// создали базовый класс
var parent = function() {};

// создали класс
// и сделали его потомком базового
var jQ = function(el) {
   this.el = document.getElementById(el);
}
extend(jQ, parent);

// добавили в класс parent методы и свойства
parent.prototype.html = function(text){
    this.el.innerHTML = text;
    return this;
};   
parent.prototype.css = function(key, value){
    this.el.style[key] = value;
    return this;
};



// Использование 
var element = new jQ('bar');
element.html('test');


Более подробно про наследование вы можете почитать:

https://learn.javascript.ru/class-inheritance

http://javascript.ru/tutorial/object/inheritance

Платформа для настольных приложений на Java

#java #framework

Изучаю Java для реализации долгосрочного проекта. При создании проекта настольного
приложения на NetBeans есть предупреждение о том, что Swing не будет дорабатываться.
Значит ли это, что новые проекты на Swing начинать не стоит?
Какую лучше платформу выбрать для настольных приложений?
Особенности использования этих платформ на NetBeans и IDEA (или в других)?    

Ответы

Ответ 1

Долгое время занимался разработкой клиентских приложений на Swing (b2b клиенты и
пр.) и пришел к такому выводу: 

Для корпоративных приложений (клиент
   банки, b2b) связка Java+Swing
   годится, когда на бекенде у
   приложения java сервер.
Для настольных GUI приложений java это зло.

К примеру такие классные апликухи как azureus или personalbrain убивают своей монструозностью.
То есть легкое десктопное приложение на джаве не получить. 
Я пока для себя остановился на wxpython+python для более менее больших приложений
где много гуя и чистый wxwidgets+c++ для апликух по меньше, где важна легковесность.

Особенности использования этих
платформ на NetBeans и IDEA (или в
других)?

Netbeans со своим визуальным редактором хорош для визуального проектирования, мышкой
накидал форму и закодил функционал, но для серьезных проектов эффективнее гуй писать
вручную, а там уже любая ide подойдет.


Ответ 2

Создано замечательное решение для создания оконных приложений: JavaFX. Там все настолько
упрощено, что и работать с ней приятно. Тем более NetBeans имеет плагины для графического
построения дизайна приложений на JavaFX.


Ответ 3

Не значит!!! Будьте спокойны! Здесь имелось ввиду Платформа приложений Swing(JSR-296)
— не Swing, библиотека для создания графического интерфейса на языке Java.

PHP фреймвок, который научит как архитектурно правильно нужно писать веб-приложения [закрыт]

#php #framework

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Update the question so it
can be answered with facts and citations by editing this post.
                        
                        Закрыт 3 года назад.
                                                                                
           
                
        
Пересмотрел кучу фреймворков, но все еще задаюсь вопросом какой именно фреймворк
нужно знать каждому php-шнику. Я не говорю о том какой лучше и быстрее из них, подскажите
академически правильно написаный фреймвок, у которого есть чему поучиться учитывая
что на дворе заканчивается 2016 год.
    

Ответы

Ответ 1

Симфони однозначный лидер.

В ней есть миллион ограничений, которые просто не дают сделать неправильно. Это сильно
бесит поначалу, но со временем понимаешь, что уставы пишутся кровью, и каждое ограничение
- это не прихоть разработчиков, а забота о тебе же самом.

К примеру, в консольной команде нельзя получить доступ к методу контроллера. И это
правильно, потому что если какой-то функционал требуется больше, чем в одном месте
- ему не место в контроллере, и он должен быть помещен в библиотеку-хелпер, а контроллер
уже должен обращаться к этому хелперу.

Ларавель, в свою очередь, очень хороший фреймворк, но он ориентирован на простоту
и скорость разработки, за счет обхода некоторых важных принципов. Чтобы не быть голословным,
вот хорошая статья про недостатки Laravel


Ответ 2

Symphony или laravel. Оба хороши.
У первого мало инструкций на Русском, у второго их по больше


Ответ 3

А я бы посоветовал не фреймворк а cms с выстроеной архитектурой что бы посмотреть
как это работает к примеру magento любой версии, время вхождения долгое, cms с ограничениями
и сложная но после того как въедишь становиться очень удобной, так как архитектура
и структура cms продуманна до мелочей.

Yii framework или обычный php?

#framework #php #yii

Здравствуйте, гуру. Недавно узнал о неком волшебном Yii framework (да и вообще о
фреймворках на php). Посмотрел, да, вещь хорошая, но я не знаю стоит ли уходить с чистого
php на него, потому что 2 их я думаю трудноват о выучить (каша в голове будет)... В
Yii я делаю приложения немного быстрее, но на php привычней... Вот сижу мучаюсь, помогите
с выбором
PHP учу уже 1,5 года
    

Ответы

Ответ 1

Ну изначально тебе стоит изучать сам язык вне зависимости от того какой фреймворк
на php ты будешь юзать.
фреймворк и язык программирования разные вещи.
Учи язык, фрейм поможет создавать приложения просто быстрее.


Ответ 2

На гуру не претендую, но могу сказать, что yii стоит того что его нужно изучить.
Будет взрыв мозга.


Ответ 3

Все верно, используй Yii framework для развертывание проектов, если боишься забыть
чистый php, возьми ученика кого нибудь_) обучение других, даст тебе отточенный инструмент,
который в любое время будет готов к бою)


Ответ 4

Изучение фреймворков это хорошая практика) Хотябы для личного опыта. В них уже реализованны
повседневные задачи, плюс вы застрахованны от ошибок при разработке(не от всех конечно).
Вывод изучайте YII)


Ответ 5

Yii - фреймверк среднего уровня, надо начинать с более простого.
http://habrahabr.ru/post/178833/

Самый быстрый (короткий) способ крашнуть вкладку [закрыт]

#javascript #jquery #framework #webbrowser #браузер

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Update the question so it
can be answered with facts and citations by editing this post.
                        
                        Закрыт 6 месяцев назад.
                                                                                
           
                
        
Как, используя минимум символов, уронить вкладку браузера / уйти в вечный цикл или
рекурсию или что-то в этом духе?

Предлагайте свои варианты на чистом js или с использованием фреймворков.
    

Ответы

Ответ 1

Или такой цикл например :D



while(1);


Ответ 2

Один из самых коротких способов открыл для себя недавно. Он на jquery.



$($)





*Спасибо всем, кто принял участие. Очень занятно было наблюдать за комментариями.


Ответ 3

19 символов



for(let a;;a+=" ");


Ответ 4

Немного поигрался в консоли, написал банальное зацикливание. Пару секунд и страница
мертвая. Я так понимаю заканчивается слишком большой объект получается.

function crash(){
let i = 1;
let a = {};
while (i > 0){
        a[i] = i++;
        console.log(a); 
    }
}
crash()


Ответ 5

Столько вариантов, предложу и я интересный) 

while(true) {
   window.open();
}


for(;;) {}

Переход на фреймворк [закрыт]

#php #framework #seo #redirect

        
             
                
                    
                        
                            Закрыт. Данный вопрос необходимо конкретизировать. Ответы
на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы он был сосредоточен только на одной проблеме, отредактировав его.
                        
                        Закрыт 3 года назад.
                                                                                
           
                
        
Есть сайт, написанный процедурно и с устаревшими подходами в PHP. Сейчас я хочу полностью
переписать его на фреймворке Laravel. Кто занимался подобным? Много ли подводных камней?

Еще вопрос, каким образом сделать правильный редирект в htaccess для поисковиков
и скорейшей правильной переиндексаии. Старый путь: 

http://site.com/items.php?item=356084821


Новый будет примерно таким: 

http://site.com/item/356084821


    

Ответы

Ответ 1

Многие программисты бояться всего нового, ибо освоение новой технологии занимает
время, лучше уж старое, но привычное, чем новое, неизведанное и не всегда лучшее. Нужно
всегда развиваться и идти вперед. На нативном PHP далеко не пойдете. 

Фреймворк - набор готовых функций, процедур и многого другого, создан для того, чтобы
избавить программиста от рутиной работы. Практически все фреймворки построены с использованием
принципов ООП и неплохо было перед разработкой с их использованием разобраться в этих
трёх буквах. Использование фреймворков — это хороший шаг, который позволяется сосредоточиться
на написании бизнес-логики вашего приложения, вместо реализации велосипедов. 

Советую смотреть в сторону таких фреймворков, как Yii, Symfony, Laravel. Вы выбрали
Laravel. Попробуйте после написания на Laravel переписать на Yii, Symfony. И сразу
поймете разницу. Главное знать сам язык хорошо, а технологии всегда меняются и требуют
внимания к себе. Кстати в Symfony очень хорошая маршрутизация. 

Удачного кодинга...

PHP скелет для не магазинных web-приложений с MVC и ActiveRecord

#php #cms #framework

История со впадением в ступор при выборе скелета - знакома тем, кто делает сайты/сервисы
радикально отличающиеся от магазинов, и сайтов-блогов/визиток. В итоге скелет для каждого
нового проекта получается методом "удалим всё ненужное из старого проекта, вот и скелет!".
Очень хочется прервать этот замкнутый круг, ведь возможно есть качественные скелеты?
Теперь к конкретике:

Под скелетом я понимаю нечто среднее между фреймворком из коробки (yii, zend например)
и CMS (wordpress, bitrix например). То есть не только архитектурное устройство, что
даёт фреймворк. Нужны также совсем базовые модули "под дописку". Какой скелет требуется
конкретно нам, и возможно многим:


Основан на любом из фреймворков с MVC, имеет модульную структуру
Работа с БД идёт через ActiveRecord, приветствуется присутствие ORM
Имеет на борту системные модули - работа с файлами с возможностью переключать хранилище
(Storage), группа компонентов для общих вещей (вроде тикетов техподдержки, тегов, поиска,
логгирования ошибок, и.т.п. модуль Utility).
Модуль пользователя с авторизацией через соцсети, с возможностью требования некоторых
перс-данных для получения полноценного статуса (User). Не обязательно, но желательно
с модулем оповещений по СМС/на-почту/на-сайт.
Минималистичная работа с контент-страницами (Article).
Не обязательно, но желаемо - платёжный модуль: балланс пользователя, услуги и подписка,
экваеринг (Billing).


Не обязательна даже админка, тем более не требуются системные вещи вроде компиляции
css, сборка react (как в magento). 

Проблема в том, что в основной массе для web штампуются интернет-магазины, блоги,
и визитки. Как только появляется необходимость иного сервиса - нам вот приходится либо
тянуть громоздкий код за собой, либо писать с нуля(неизвестно даже что быстрее и лучше
выходит). Можно было бы обрезать модули одной из существующих CMS - но во первых: не
помню бесплатных CMS, которые активно используют ActiveRecord (это важное требование),
во вторых они все очень избыточны запутаны: то есть апгрейд заточен там под обновления
от авторов CMS/модулей и настройку модулей, а не под "дописку" кода. И даже если несмотря
на всё выбрать дописку CMS - это отказ от обновления - а это в свою очередь делает
систему недолговечной в плане безопасности.

Но может быть мы отстали, и подобных качественных скелетов уже много? Или в общем
альтернатив нет? Подскажите пожалуйста, на какие продукты стоит обратить внимание.

P.S. Вопрос не совсем в тематике SO, так как предполагает в ответе мнение о скелете,
тем не менее для автора он очень горяч и актуален.
    

Ответы

Ответ 1

Я могу порекомендовать обратить внимание на фреймворк Laravel в связке с админкой
Sleeping Owl для создания типовых crud-операций.

Laravel -- один из наиболее популярных PHP-движков в Европе, сейчас это там стандарт
де факто. В качестве подтверждения могу привести линк на stackoverflow trends.

Каким вашим требованиям удовлетворяет:


модульная структура
mvc из коробки (впрочем, это сейчас во всех популярных движках), поддержка роутингов,
контроллеров, миддлвари и т.п.
ActiveRecord из коробки и ORM из коробки (с учётом модульности -- можно заменять
на другие варианты)
имеет модуль работы с файловой системой (абстракция, которая поддерживает не только
локальные файлы, но и работу с облачными файловыми системами)
интеграция с соцсетями из коробки, возможно придётся для каких-то соцсеток писать
собственные провайдеры -- но проще поставить пакет Socialite


Crud-админки не являются частью движка, нужно ставить сторонние решения поверх. Одна
из самых популярных админок -- Sleeping Owl, поддерживается русскоязычным коммьюнити,
шлёпать админки с ней -- одно удовольствие.

Работа с контент-страницами тоже часть админки -- поэтому описываю в этом пункте.

Чего нет в коробке:


Работа с тикетами
Билинг
Корзина покупок (можно поискать готовые модули, например Crinsane или создать свой)


Ответ 2

Первое, что приходит в голову - MaxSite CMS
, сама по себе освнована на MVC фреймворке CodeIgniter и ориентирована как раз на
то, что дописывать модули и виджеты будете сами. а по большому счету полностью универсальных
решений не бывает, тут либо смириться с недостатками существующих CMS, или писать что-то
свое под свои цели


Ответ 3

Рекомендую Yii2 фреймворк. На мой взгляд, это лучшая платформа из всех фреймворков
и CMS с которыми я когда-либо работал. Там есть все, о чем вы просили. Если будете
выбирать фреймворк, то только Yii2, и никакой ни Laravel, как пишут в другом ответе!
Там и половины нет тех возможностей, что есть в Yii2. Перечислю основные плюсы специально
в вашем контексте:


Мощный встроенный инструмент генерации кода. Админки любой сложности
штампуются на раз, и безо всяких ошибок в коде.
Расширений под Yii написано масса, и это далеко не базовые модули. Найти можно все
что угодно.


ActiveRecord, Виджеты, RESTful API, генерация документации, PJAX с которым вообще
забываешь про написание AJAX-ов в backend, мощная система ролей RBAC, I18N со сканированием
всего проекта, разделение приложения на frontend и backend и много другого.
Один минус - порог вхождения не малый. В тот же Laravel гораздо проще стартануть,
но и возможностей будет намного меньше. 

Удачи с выбором! ;)

Фреймворк для браузерной игры

#framework #php #разработка_игр

Сейчас один достаточно компетентный человек сказал мне, что браузерную игру лучше
всего делать без фреймворка, т.к. тогда достигается наибольшая скорость, а фреймворки
(даже самые быстрые) тянут с собой слишком много для таких проектов, в т.ч. роутинг
тратит слишком много ресурсов. Подскажите, стоит ли делать браузерку на основе фреймворка
(я присмотрел CodeIgniter), или лучше с нуля?    

Ответы

Ответ 1

Если есть время, напишите с нуля. Получите опыт и на ошибках поймете что и как. А
потом уже можно и на фреймворке.


Ответ 2

Если выбирать фреймворк для игры посмотри на эти:

Crafty

Легкий модульный игровой движок, включающий множество функций: анимацию, управление
событиями, перерисовку регионов, отслеживание пересечений и столкновений, спрайтовую
графику и многое другое. Поддерживает все браузеры, в т.ч. IE9. Никаких дополнительных
усилий прилагать не требуется.

Quintus

Quintus – игровой HTML5-движок, разработанный, чтобы быть модульным и легковесным,
с четким JavaScript-подобным интерфейсом. Для того, чтобы реализовать основные особенности
ООП-игрового движка в HTML5-движке, в Quintus в некотором отношении схож с jQuery,
а также поддерживает плагины, управление событиями и гибкую модель наследования, чтобы
упростить повторное использование реализованных функций.

gameQuery

Простой в использовании плагин jQuery, упрощающий разработку игры за счет использования
реализованных игровых компонентов. Благодаря особенностям реализации совместим со множеством
браузеров, в т.ч. их мобильными версиями.

GMP

Идеально подойдет для реализации 2D спрайтовых аркад в ретро-стиле и головоломок
вроде Судоку. Он имеет готовый к использованию самозапускающийся игровой цикл. Поддерживаются
мышь и клавиатура. Отлично документирован, и главным недостатком можно считать только
отсутствие поддержки звуков.

lycheeJS

Игровая библиотека JavaScript, которая предлагает готовое решение для проектирования
и реализации HTML5 Canvas и WebGL или нативных OpenGL игр внутри браузера или стационарных
платформ. Оптимизирован для Google Chrome.

Enchant.js

Фреймворк Enchant.js для HTML5+JavaScript игр был разработан в 2011 году, распространяется
с открытым исходным кодом (MIT лицензия) и потому бесплатен.

The Render Engine

Кросс-браузерный опенсорсный движок, написанный полностью на JavаScript. Созданный
с нуля для того, чтобы быть максимально гибким, он имеет обширный API и использует
самые новые фичи современных браузеров. Этот фреймворк предназначен, чтобы делать все
за вас: ваша идея – его реализация с помощью самых часто используемых инструментов.

GameJS

Большая библиотека на верхнем уровне HTML Canvas. В добавок к функциям рисования
в ней имеется растущий ассортимент полезных для разработки игр модулей. Большинство
имеющегося API основан на популярной PyGame.

CSS Game Engine

Для формирования страницы используются JavaScript и CSS. Вместе они работают достаточно
уверенно и слаженно. Разработан для новичков, обучающихся азам программирования видеоигр.
Вам будет проще, если у вас уже есть какие-то навыки работы с CSS.

ClanFX

clanfx основан на JavaScript и CSS и использует плиточную графику. Работает на данный
момент в Firefox, Epiphany и Opera. Среди реализованных фич: анимированные спрайты,
эффекты заклинаний, постройки, плитки/текстуры и базовый искусственный интеллект.

gTile

Браузерный движок на чистом JavaScript и DHTML. В gTile плиточная графика была выбрана
за ее простоту и доступность. Упор в реализации был сделан на высокий уровень интерактивности
и поведении игровых объектов. Меньшее внимание было уделено графике. А потому движок
подойдет больше для создания текстовых РПГ, а графических возможностей должно хватить
для изображения локаций.

J5g3

Графический JS движок с открытым исходным кодом (GPLv3). Легкий в использовании синтаксис
предназначен для того, чтобы сделать фреймворк быстрым и расширяемым.

Jaws

2D игровая библиотека, основанная на HTML5. Использует и Canvas, и средства DOM.

Cocos2D

Портированный с iPhone графический 2D HTML5-движок на JavaScript. Позволяет быстро
создавать 2D игры и графические приложения, которые могут работать на всех современных
устройствах без установки дополнительных плагинов.

CopperLicht

WebGL библиотека и JavaScript 3D движок для создания браузерных игр и 3D приложений.
Использует WebGL Canvas, поддерживаемый современными браузерами и способный поддерживать
рендеринг 3D моделей, используя аппаратное ускорение без плагинов.

Aves

Этот HTML/JavaScript движок – реинкарнация набора инструментов для разработки олдскульных
RPG (но с более привлекательной графикой). И все только с помощью HTML и JS. Никаких
плагинов. Никакого Flash.

LimeJS

HTML5 движок для разработки игр с поддержкой сенсорного ввода. LimeJS создан с использованием
Closure Library, созданной Google, и в нем уже реализованы классы и функции для отслеживания
времени, событий, обработки форм и анимации. Также фреймворк поддерживает спрайтовые
листы (т.е. все используемые изображения могут быть помещены в один файл).

Phaser

Ещё один фреймворк для создания мобильных и десктопных игр на HTML5 с применением
Canvas и WebGL. Бесплатный и с открытым исходным кодом. Есть быстрые гайды для старта
на JavaScript и TypeScript.


Ответ 3

Страдал аналогичным, фреймворки сам не люблю, да они тянут слишком много и ресурсы
жрут от 5-100 раз. Но в чистый js, css3, вьезжать будет дольше. НО эффективнее намного
и гибче! Опять НО, если цель единична, игра, то это не профи область для разработчиков,
то есть смысл юзать фреймворки! Ибо зачем оптимизация в браузерной игре?! Эти области
это всегда первые шаги и учеба, саморазвитие!

Фреймворк PHP нужен ли? [закрыт]

#framework #php

        
             
                
                    
                        
                            Закрыт. Этот вопрос не по теме. Ответы на него в данный
момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Update the question so it's
on-topic for Stack Overflow на русском.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Здравствуйте, сколько программирую на php, не разу не использовал в этой среде фреймворк.
Мне хотелось узнать для оптимизации лучше использовать чистый код или использовать
фреймворк. Хотелось поинтересоваться, есть ли отличия от обычного кода, кто может расскажите,
буду рад адекватному ответу.
Спасибо за внимание!
    

Ответы

Ответ 1

Любой фреймворк - это, в первую очередь, набор стандартов которые знают разработчики.
Вокруг популярных фреймворков собирается серьезное сообщество разработчиков, а значит
легко подключить или заменить человека в команде работающей над проектом.
Плюс, комьюнити создает массу готовых сторонних решений.


Ответ 2

Почти любой фреймворк создан с целью ускорить разработку, поддержку.
Скорости работы приложения это, при прочих равных, не добавляет.
Правда, учитывая что многие люди пишут резко неоптимальный код, те же действия на
фреймворке срабатывают быстрее и чище.


Ответ 3

Фреймворк позволяет не изобретать велосипеды, иметь удобный доступ к базе (DAO),
и гибкость. Я бы советовал начать с Code Igniter (по нему много документации на русском). 
Хотелось бы также отметить MVC-подход в фреймворках. Он позволяет без особого труда
изменить/добавить тему оформления сайта и т.д.

Что такое framework и runtime?

#framework #runtime

Нигде не нашел чёткого опрделения этми двумя понятиям.

Я понимаю фреймворк, как платформу, которая необходима для работы каких-либо приложений.
Например, набор динамически линкуемых библиотек для нескольких приложений - уже фреймворк.
Также под это определение подохдит и Java Runtime Environment (в том числе и JVM).
Однако что такое рантайм? С одной стороны это всего лишь фаза выполнения программы.
С другой стороны есть куча терминов, как runtime libraries, runtime system... Что вкладывает
майкрософт в это понятие тоже неясно. Объясните, пожалуйста!
    

Ответы

Ответ 1

Между библиотекой и фреймворком разница небольшая, но принципиальна. Если Ваш код
просто использует функции модуля, то этот модуль скорее всего библиотека. А вот если
модуль заставляет Вас писать код так как он хочет и сам его вызывает, то это уже фреймворк.
А вот собственно модуль - это набор файлов-исходников (иногда уже скомпилированных).

runtime - это часть кода, существует в выполнимом файле (либо в отдельных so/dll)
и обеспечивает всякие "удобства". Например, узнать тип объекта или сделать те же виртуальные
вызовы. Добавляется обычно компилятором и обычный пользователь может даже не знать
о нем. Также словом runtime называют то время, когда программа выполняется. Что конкретно
имеется ввиду - нужно сдедить за контекстом.

runtime libraries - это библиотеки, которые используются во время работы программы.
Иногда библиотеки поставляются в двух видах - для разработки и для обычной работы (вторые
часто оптимизированы и с них выброшено лишнее). Хороший пример - bpl файлы делфи. Для
одного и того же компонента могут быть библиотеки, которые содержат всякие инструметы
для IDE, а есть которые только для работоспособности кода.

JRE - это не фреймворк, это runtime библиотека. Хотя с другой стороны это фреймворк
для байткода. Но так как на байткоде пищут только особые извращенцы, то обычному программисту
это не фреймфорк. А вот вся java - это один сплошной фреймворк:)


Ответ 2

Хотелось бы немного дополнить данный ранее ответ.


Framework vs Library. И то, и то - набор каких-то полезностей и функциональностей,
но принципиальная разница в Inversion Of Control.
Поясню: представь себе консольное приложение, в которым ты
спрашиваешь у пользователя какие-то данные, а затем
проводишь вычисления и отдаешь результат. В ходе вычислений ты
можешь использовать, например, библиотеку математических функций, но
ты САМ задаешь ход и структуру программы, а функциями из библиотеки просто пользуешься
по мере необходимости. Во фреймворках же происходит инверсия контроля, т.е. 
ход программы определяет ФРЕЙМВОРК, а тебе надо как бы заполнить 
определенные пустые места своим кодом (например, написать контроллер в MVC-
фреймворках).
Runtime. Под "runtime" скорее всего ты имеешь в виду вспомогательные
программы, которые используются при исполнении основных программ через 
определенное API. Например, JS-движок браузера использует event loop и через
разные API (например, XMLHttpRequest) получает дополнительные возможности, которые
к самому JS не относятся. Эти API по сути и есть runtime, которые расширяют возможности
и помогают выполнить код скрипта. При этом со стороны, взаимодействуя с API, может
показаться, что эти возможности как бы принадлежат самому JS или же являются вызовами
каких-то библиотечных функций, хотя на самом деле они могут быть реализованы вообще
по-другому и к JS отношение не имеют.

Свой фрэймворк вместо QOOXDOO. ООП-шим Яваскрипт.

#framework #javascript

Доброго времени суток.
Задался я целью на работе - избежать использования такого фрэймворка как QOOXDOO.
Он, конечно, классный и прикольный, но, к сожалению, и питон нужен для компиляции
кода (да-да, чтобы собрать воедино код, нужен Питон), а еще он весит 100500 метров. 
В общем, старался обойти без потерь для текущего проекта. Получилось вроде бы.
Из возможностей: 

Возможность создания класса и его экземпляров. 
Текущие типы классов, возможные для создания - динамический, синглтон.
Возможность "подмешивания" методов сторонних классов (МИКС).
чОткое наследование
Автоматическое создание Геттеров, сеттеров и листинга и контроля типов для публичный
переменных.
Возможность создания статических методов вне статических классов.

оооооОоОооочень маленький.
Текущие недоработки (будут исправлены в течении пары дней...когда высплюсь):


Нет возможности наследования синглтона. (функции написаны, но начинку не пихал. Там
все просто)


Пример простейшего класса: 
// Mixin class
smc.define("MTest", {
         // Static methds & properties
        static: {
                base: 0x100,
                unit: 0x200,
                resouce: 0x300
        }
});
// Mixin class
smc.define("MTest2", {
        // Static methds & properties
        static: {
                moto: 0x100,
                auto: 0x200,
                velo: 0x300
        }
});

smc.define("MyFirstClass", {
        /*
        * Конструктор. Вызывается при создании нового экземпляра класса.
        */
        construct: function (a,b) {
                if(a) this.setName(a);
                if(b) this.setMessage(b);
                this.helloWorld();
        },
        /*
        * Это примесь. Вы можете создать массив и указать SMC классы, 
        * чьи свойства необходимо подмешать в текущий объект класса.
        * Если такие классы есть - Вы сможете вызвать их методы, из текущего экземпляра,
        * либо обратится к их переменным
        */
        mixins: [
                smc.MTest,
                smc.MTest2
        ],
        /*  
        *  Это паблик- переменные класса.
        * value: Значение переменной
        * type: тип переменной (дефолт- любой)
        * event: Если при изменении значения переменной необходимо вызвать какую-либо
функцию, 
        */
        properties: {
                name: { value: "Станислав", type: "string" },
                message: { value: "Привет", type: "string", apply: "this.helloWorld" }
        },
        /*
        * Список паблик функций, либо переменных
        * (как правило, сюда забрасываются переменные, которые не нуждаются в паблик
доступе)
        */
        members: {
                helloWorld: function () {
                        alert( this.getMesage() + ", " + this.getName());
                }
        },
        static: {
                whatAreFuck: function () { console.log("Это простой статический метод
у динамического объекта. Может вызываться без создания экземпляра класса") }
        }
});

Скачать его можно пройдя по этой ссылке :)
http://download.tracking.by/smc.js    

Ответы

Ответ 1

:) ЗАчетно, действительно, ничего тяжелого :) Но есть и нюансы.
1. Сразу бросилось в глаза с примером создания Юзера и Админа. Практически копипаст
содержания одного объекта и второго. Думаю, никто не возразит, если я скажу, что это
немного некрасиво :) Ну да ладно, тут дело вкуса, не имею права ничего говорить :)
Вот, хотел обратить внимание на фразу :
" сеттеры, геттеры и т.д и т.п. не стал т.к. не считаю целесообразным ( надо будет
- можно написать "класс" с этим функционалом от которого, потом, расширять все )."
Не стоит расширять функционал за счет таковых лесапедов :) Тут фишка в чем. Почему
я задался вопросом о реализации сеттеров и геттеров - очевидно.

Можно запросто контролировать типы переменных (а порой это очень важно)
Не придется писать к каждому геттеру и сеттеру функции всякие познавательные :) Как
говориццо "Все уже сделано до нас:)" ... да и размер кода существенно уменьшается.
:) У меня просто позиция такая - чем больше сделаешь сейчас - тем меньше потом делать
всего :)


Ответ 2

И что, вот так можно вызвать функцию?
MyFirstClass::whatAreFuck();

А вообще круто.

Обязательны ли Фреймворки в C# для проектирования?

#c_sharp #mvvm #framework #mvvm_light

Можно создавать MVVM программы на C# без использования таких фреймворков например
как MVVM Light Toolkit? И очень ли сложно будет без них обойтись?
    

Ответы

Ответ 1

MVVM - это только паттерн проектирования, а значит если вы понимаете паттерн, то
есть у вас готовый фреймворк или нет не имеет значения.

В основном, необходимость использовать фреймворки и библиотеки исходит из масштаба
проекта, решаемых задач, существующей кодовой базы и предпочтений тимлидов. Если проект
большой и не использовались сторонние разработки, то большая часть вашей кодовой базы
и будет тем самым фреймворком.

А теперь более важные вопросы: Насколько большой проект? Сколько человек над ним
работает? Насколько хорошо документирован ваш код? Сколько времени понадобится новому
разработчику чтобы изучить и начать эффективно его использовать? В случае распространенных
фреймворков эти вопросы стоят не так остро, т.к. в каком-то виде документация обычно
есть, иногда есть техподдержка производителя, в сети достаточно решений типичных проблем
на тематических форумах, EnSO и тут.

Для небольшого проекта острой необходимости в тяжелых фреймворках нет, более того,
за счет отсутствия тяжелых и неповоротливых "монстров" небольшой проект даже выиграет,
если не надумает расти конечно. В случае большого проекта все не так однозначно.

И да, это касается не только упомянутого вами MVVM, но и всех остальных областей,
будь то WEB, работа с базами данных и т.д.


Ответ 2

Фреймворки не обязательны.

Я вот обхожусь, острой необходимости в использовании фреймворка пока что не возникало.
Мелкие удобства вполне делаются вручную.

Разница между фрэймворком, библиотекой и API?

Так в чём на самом деле разница между фрэймворком, библиотекой и API?
Есть мнение, что всё это близкие понятия, везде есть классы и методы которые можно встроить в клиентский код.
И всё же, похоже есть существенные отличия?
    

Ответы

Ответ 1

Начнём с API. Это самый простой вариант: возможность для приложения обратиться 
коду вне этого приложения. Это набор функциональности для того, чтобы заставить внешнюю для программы сущность сделать свою работу.

Пример из реальной жизни: у вас есть в квартире водопровод, а API — телефон сантехника, который этот водопровод может починить, если надо.

Теперь, библиотека — это готовый к использованию набор кода, который бежит в контекст
приложения, и точно так же выполняет свою работу. То есть библиотека становится пр
подключении частью приложения. Разница между библиотекой и API может быть довольно тонкой: например, WinAPI предоставляет функциональность, которая в общем-то иногда происходит и в рамках процесса. Тем не менее, это считается обращением к внешней для приложения платформе.

Пример из реальной жизни: вы сами не сколачиваете шкаф, а покупаете домой готовый, ставите в свою квартиру и пользуетесь им. Шкаф — ваша подключаемая библиотека.

Ну и фреймворк — его функции, в отличие от библиотеки, не вызываются вами, а наоборот
ваш код вызывается из него. Фреймворк можно представить себе в виде полуфабриката приложения, к которому вы дописываете нужную функциональность сами.

Пример из реальной жизни: вы покупаете почти готовую квартиру, а мебель, обои и шкаф
добавляете сами. Квартира — ваш фреймворк, она уже почти готова. Вы не можете так просто переделать число комнат или превратить её в корабль, вместо этого вы только добавляете внутреннюю функциональность: паркетный пол, махровый халат в ванной и кота.


Ответ 2

Если Вы попользуетесь каждым поймете разницу.

API:

Чаще всего подразумевает интерфейс взаимодействия. Используется для работы с независимым
сервисами. Допустим, Вы хотите выкладывать видео на YouTube, то будете пользоваться их функциональностью через API.

Библиотека:

Чаще всего набор готовых классов, методов, решений типичных задач. Заточеных по
что то определенное. Допустим, Вы хотите распознавать лица на фотографиях (собственноручно, не используя сторонние сервисы), то установите какую-то OpenCV и будете ее использовать, что бы не изобретать велосипед заново.

Фреймворк:

Чаще всего включают в себя библиотеки для удобства. И предоставляют Вам готовый шаблон/
приложения, реализуя паттерны проектирования (MVC, MVVC или другие). Фреймворк обычн
состоит из готовых модулей, которые между собой жестко связаны (используют интерфейсы друг-друга), при разработке своего модуля необходимо реализовывать интерфейсы для прощей интеграции своих модулей.


Ответ 3

API - это интерфейс взаимодействия с программой извне. У Вас есть сам по себе какой-т
готовый продукт и он представляется черным ящиком и Вы хотите, что бы им могли пользоватьс
другие программы. Вы определяете методы взаимодействия с ним и описываете их, а сторонние программы им пользуются. Само по себе понятие очень широкое и чаще его все же используют по отношению к удаленным сервисам и запросам вне основного приложения. Грубо говоря API - описание взаимодействия с черным ящиком, что бы он сделал Вам то или иное действие.

Библиотека - это сборка различный функций и подпрограмм, которая может быть перенесен
и использоваться потом в различных приложениях. Основная идея в том, что они переносимы между приложениями и могут быть многократно использованы без изменений.

Фреймворк - это каркас для будущего приложения, в котором собраны все основные необходимы
детали: библиотеки, структура, начальный код и т.д. Можно сказать, это минимальная заготовка, на основе которой Вы будете дописывать функционал и строить дальше приложение. Ваше приложение будет работать за счет того, что уже есть и заботливо для Вас заготовлено.


Ответ 4

Библиотека как правило маленькая, создана для чего-то определенного, как правило, одной цели. Например, библиотека календарь на js, график на winforms.

API - это выставленный напоказ интерфейс системы: методы, классы и тд, которыми другие люди могут пользоваться.

Framework - большая система, охватывает многие вопросы по какой-либо теме. Например
.NET Framework. Это куча библиотек для самых разных нужд. Можно писать как веб-приложения, так и winforms, wpf, wcf и другие.


Ответ 5

API это паттерн.

Библиотеки и фреймворки предоставляют API.

API может создаваться на базе фреймворка.

Фреймворк состоит из библиотек или являет собой паттерн их соединения.

Библиотека может собираться фреймворком платформы.


Ответ 6

Если на пальцах, то так:


Библиотека - это какая-то внешняя логика, к которой ваш код может свободно обращаться, чтобы дёргать некий функционал.
Фреймворк - это какой-то готовый каркас, в рамки которого вы должны вписать ваш код.
АПИ - это пульт управления, который некоторая система выставляет наружу, чтобы другие системы могли к ней обращаться.


Ответ 7

Api (appliation interface)  - доступ к функционалу приложения. Библиотека (сборка
 - отдельный модуль содержащий набор классов или методов.  Ну и framework это не прост
набор функционала как api, sdk или библиотека - это полноценная среда разработки,  помимо набора классов и методов которые могут быть использованы в вашем приложении фрэймворк дает, нужное подчеркнуть, компилятор, интерпретатор, менеджер пакетов, декомпилятор и многое другое. Например. Net,  nodejs, java являются фрэймворками.


Ответ 8

поправьте, если не прав ХОТЬ В ЧЕМ-ТО.
Библиотека (*.dll)- тупо примитивно ДРАЙВЕРА.(Отличие драйвера от программы - отсутстви
в коде драйвера точки входа (так называемой и всеми любимой функции "main(){}" ...). без psv main(){} программа становится библиотекой (набором классов).
Фрэймвок - это СДК, использующий АПИ(которая в свою очередь использует *.dll библиотеки/драйвера)
Фрэймворк - это SDK, работающий с помощью API.

Язык программирования для разработки игр [закрыт]

Насколько мне известно, в gamedev сложилась традиция использовать C++. (Irrlicht, Ogre, Unreal Engine). (Хотя Quake Engine написан на C).
C++ это один из языков, где легко прострелить себе ногу (по большей части из-за тог
что он основан на Си), и чтобы писать код на нём нужно обладать большим опытом и профессионализмом. Нужно знать возможные грабли. (Отсутсвие модульной системы добавляет боли)
У меня есть подозрение, что использования C++ можно избежать.
Теперь компьютеры стали быстрее.
C++ хвалят за возможность специализации (с помощью шаблонов) методов для конкретны
типов данных. (Это позволяет выполнять код без лишних вызовов, хотя это и раздувает код).
Но ведь ту же специализацию можно сделать с помощью JIT. Или, например, весь быстры
код можно записывать с помощью eDSL, с компиляцией в рантайме (к примеру с помощью LLVM). Более того, этот подход может дать более быстрое выполнение чем специализированные методы C++, т.к. в рантайме доступно больше информации, и можно оптимизировать больше.
Наверняка кто-нибудь до этого уже додумался.
Собственно вопрос: Пишет ли кто-нибудь игры (или графические/игровые движки) не н
C++? Какие есть проекты? Особенно интересуют проекты где необходимы быстрые вычисления.    

Ответы

Ответ 1

1) O'Caml или другой из ML-family. Бенчмарк, где кресты глотают пыль.
2) Lisp. Warcraft 2 in 1300 lines (eDSL на Lisp).
3) Object Pascal. Казуалка (с сервером на Haskell).
4) Любой другой, кроме крестов, если, разумеется, не стоит цель прострелить ног
всеми возможными способами и вдоволь насосаться леденца.


Ответ 2

Хотя мощности и повысились, но и уровень игрушек повысился. Если вы хотите писать игры уровня 2000 года то да, можете хоть Java использовать. 
Для современных же проектов лучше всё же C++ и даже ассемблерная оптимизация. 
Если не хочется изучать С++ то советую посмотреть на игровой движек Unity 3D, гд
написание управляющего кода возможно на JavaScript, C#, Python(Boo) а вскоре обещают и ActionScript для компилирующихся во флеш проектов. 
Кстати не стоит думать что вы пишете прямой исполняемый код на этих языках. Все скрипт
написаные в редакторе будут скомпилированны. Например реализация JS в Unity почти в два раза быстрее оригинального.


Ответ 3

Я бы разделил игровой проекта на отдельные крупные области и использовал в каждой из них приемлимые средства, выстраивая неких стек:


Графический движок. Тут работа с нижележащими API (OpenGL, DirectX), работа с буферами памяти, шейдерами, процедурная генерация, жесткие оптимизации. Здесь C++ вне конкуренции. 
Игровая логика. Как правило в конечном счете это просчет взаимодействий объекто
с объектами. Причем объекты вполне соответствуют объектам в традиционном ООП понимании.Действи
одних объектов, могут вызывать реакции в других; объекты могут образовывать сложные иерархии. Удобно воспользоваться объектно-ориентированным языком с автоматической сборкой мусора, чтобы сосредоточиться на поведении игровой среды. Например, C#, Java, Python, Ruby. 
Алгоритмическая база. Различные варианты AI, работа с графами и сложными структурам
данных, поиски и сортировки. Задачи, типичные для функциональных языков. F#, Scala, Lisp, Haskell, OCaml, Clojure.


Разумеется, не стоит разводить зоопарк трудносовместимых сред в одном проекте. Н
некоторые комбинации могут быть вполне эффективными: C++/Java/Scala, C++/C#/F#, C++/Python


Ответ 4

Лично я пишу с XNA Game Studio + Visual Studio Express (C#).

легко писать код
много информации в интернете
можно написать что-то типа такого: http://exdream.com/XnaRacingGame/
и т. д.


Ответ 5

Minecraft написан на Java. можете погуглить на эту тему


Ответ 6

Цивилизация - движок ест-но на плюсах, а скриптование на Python
World Of Warcraft - скриптование на Lua
Ну а небольшие и 2D игры можно писать целиком на интерпретируемых языках, используя порты движков навроде Box2D.


Ответ 7

На .Net вполне приличные игрушки можно делать, например есть игровой движок NeoAxis Engine ну и как писали ранее XNA, Unity 3D


Ответ 8

Для начала надо определиться с несколькими вопросами, потому что ответить на вопрос в общей форме "На каком языке писать игру?" невозможно в принципе.

Во-первых, какую игру вы собираетесь писать? Варианты ответа:


Игру ААА-класса, чтоб убер-графика, убер-эффекты, всё реалистичное, чтоб у игрока челюсть отваливалась от одного скриншота.
Серединка-наполовинку: полу-инди с полу-убер-графикой.
Хлам для мобилок и браузеров: геймплей — ничто, монетизация — всё!
Тру-инди: из графики только пикселизованные монстрики. Вся суть — геймплей!


Во-вторых, кто вы по профессии? Варианты ответа:


Крутейший специалист по компьютерной графике, доктор по алгебре и дискретной математике, ассемблер — ваш родной язык, шейдеры пишете с закрытыми глазами.
Простой смертный программист.
Первый раз видите компьютер вживую. Про языки программирования что-то в последний раз слышали в школе.


В-третьих, кто вы по отношению к игре?


Автор, владелец, вдохновитель.
Шестерёнка в компании.
Только сейчас задумались о гейм-деве.


Теперь, когда вы держите в уме ответы на эти вопросы, можно заняться разбором вариантов.

*1* Если вы крутейший специалист, то вы не читаете этот вопрос. Пропускаем.

1*1 Если вы заправляете разработкой ААА-игр, то вы тоже не читаете этот вопрос.

**2 Если вы работаете на кого-то, то выбора у вас нет. Ха-ха-ха.

1** Если вы хотите заниматься разработкой игр AAA-класса, то есть некоторый выбор.

13* Если вы простой смертный, решивший приобщиться к разработке самых дорогих игр, то выбора особо нет.

На данный момент практически все игры ААА-класса пишутся на C++, как самом подходяще
для этой цели: практически все существующие, актуальные и передовые средства разработк
(библиотеки, программы, инструменты) поддерживают C++; это один из немногих языков, который позволяет опускаться так низко к железу, насколько надо (ближе только C); на C++ написано огромное количество кода во многих компаниях, у него огромное наследие — пожалуй, самое огромное из всех языков на данный момент.

Для мелких фиговин, типа скриптов для управления интерфейсом, могут использоватьс
другие языки — менее шустрые, но которые легко обновлять и писать: Lua и прочие. Обычно они составляют не самую большую часть логики.

Или вы уже разрабатываете, или только собираетесь — выбора у вас нет, C++ надо изучать, если хотите заниматься разработкой всерьёз, а не клепать скриптики.

Есть, конечно, вероятность, что через некоторое время будет создан "убийца плюсов"
но пока дела на этом фронте продвигаются неважно. Если вдруг продвинутся, то вы будете об этом знать — всё-таки событие мирового масштаба.

22* Если ваша игра обойдётся без самой совершенной графики, и вы умеете программировать, то у вас уже есть выбор.

Чем меньше у вас сложной логики, тем свободнее выбор языка. Если у вас тьма тьмуща
сложных алгоритмов, например, в вашей игре моделируются какие-то сложные процессы, т
эти алгоритмы придётся писать на C++. Как вариант, можно посмотреть в сторону функциональных языков, но это на любителя: чем больше языков в программе, тем больше сложностей, особенно когда в команде вы не один.

Если нагрузка на CPU ограничена, то вы можете воспользоваться тем фактом, что CP
— отдельно, GPU — отдельно. Если вы даже из самого медленного языка отправите на отрисовк
пучок графических операций, то они отработают быстро, потому что они будут выполняться отдельно от вашего тормозного кода. Сейчас, когда компьютеры стали достаточно быстрыми, часто ресурсов хватает на все дополнительные тормоза, которые возникают из-за управляемого кода (C#, Java и т.д.).

Отдельно надо упомянуть сборку мусора: чем сложнее логика, чем вы придирчевее к частот
кадров, тем менее доступным становится это удобство. Если логика разрастётся, то с большо
вероятностью может оказаться, что от сборки мусора вообще придётся отказаться и повсеместно использовать пулы и прочие подобные средства. Дело в том, что сборка мусора, какой бы быстрой она ни была, на данный момент слишком медленная, чтобы не приводить к пропущенным кадрам. Мусор, генерируемый со скорость 60 кадров в секунду, разрастается слишком быстро.

23* Если вы ничего толком не умеете, то писать сложные игры в качестве первой попытки не стоит. Начните с чего-нибудь попроще.

42* Если графика у вас относительно простая, а сложных ресурсоёмких алгоритмов нет, то ваш выбор становится очень широк.

Вы можете писать абсолютно на чём угодно! Игру можно писать на любом интерпретируемо
языке, который на порядки медленнее оптимизированого кода на C++. Какая разница, если игрок не заметит?

И чем меньше у вас команда, тем более диким может быть ваш выбор. Если вы в команд
единственный программист, то можно писать на любом эзотерическом языке программирования, ведь это никому не помешает, а вы получите от этого истинное удовольствие.

Если у вас есть какая-никакая команда, то лучше всё-таки считаться со мнением окружающи
и не использовать языки и инструменты, про которые никто не слышал. Даже если ваша текуща
команда знает их, потом может оказаться, что найти замену человеку невозможно. Используйте проверенные временем инструменты, используйте мейнстримовые языки программирования. Может, это и ухудшит производительность труда, но риск оказаться ни с чем будет заметно ниже.

43* Если вы не умеете программировать, то вы на распутье: вам или надо научитьс
программировать, или воспользоваться более простыми средствами разработки игр.

Пугаться программирования не надо. Кто знает, может, у вас скрытый талант? Есть истори
успеха, когда художник, впервые увидивший код, пишет успешную игру практически в одиночку и выигрывает кучу призов.

Но есть и путь проще: движки для игр, предназначенные для непрограммистов. Там в
будете рисовать нужное вам, расставлять свойства, копировать скриптики и смотреть, ка
оно всё шевелится. Но чем сложнее игра, тем больше нужно кода. Подобные движки часто сильно ограничивают свободу творчества, поэтому выбирайте сами, в каком направлении лучше двигаться.

3** И напоследок: если вы пишете для мобилок и браузеров, то вы имеете уникальну
возможность настолько же быстро упираться в аппаратные ограничения, как и игры ААА-класса (которые для мобилок существуют с точки зрения денег, но не с точки зрения результата, но это так, лирическое отступление).

Здесь ваш выбор будет сильно ограничен платформой (или платформами). Для одной платформ
"родной" один язык, для другой — другой. Выбор, на чём писать кросс-платформенные игры
невелик. Писать код на управляемых языках придётся немного по-другому, уделяя пристальное внимание сборке мусора. Здесь вы будете убиваться об стенку, чтобы ваша игра нормально работала на всех устройствах.

Так как ни одна платформа не доминирует, то сразу смотрите в сторону кросс-платформенны
движков и библиотек. Псевдо-ААА тоже сплошником на нём пишется, и это никого не смущает. Так как разнообразие невелико, то в трёх соснах не заблудитесь.

P.S. Я ещё не рассмотрел тьму тьмущую вещей: для какой платформы вы пишете, как выбирать движок и т.п. Считайте это общим вектором, а не инструкцией по применению.


Ответ 9

На Haskell, скажем, вполне себе успешно пишут, например, 3DFPS Frag, паззл Rainca
или платформер Nikki and the Robots (хотя в последнем физический движок взят готовый
написанный на C). Игры, учитывая их ясно некоммерческое происхождение (тот же Frag, скажем — диссертация), вполне себе приличны, так что явно не скажешь, что не написать ничего хорошего.
С другой стороны, впрочем, Кармак на QuakeCon говорил, что со скриптовыми интерпретаторам
лучше не связываться, и что с ActionScript, скажем, они огребли достаточно проблем. И с его опытом не поспоришь, хотя, с другой стороны, его опыт относится к достаточно конкретной игровой нише.


Ответ 10

Пишу лёгкие игры (целых две штука) на Objective C для iOS. О популярности данно
отрасли можете судить сами по размеру AppStore


Ответ 11

Можно писать на разных языках, даже на скриптовом Lua. А движки здесь посмотрет
можете всевозможные - gcup.ru


Ответ 12

Если вы собираетесь писать серьезные игровые движки, то выбор один это С++.
Тем более С++ не так страшен, как о нем говорят. Сейчас многие унижают С++. Называю
его мертвым языком, но вы должны понимать что это в основном маркетинг таких гиганто
как Microsoft и Oracle, которые пиарят свои продукты C# и Java. Фраза про выстрел в ногу не исключение. Стоить заметить, что та же Microsoft все свои разработки пишет на С++. В любом случае более богатые возможности языка С++ я всегда считал плюсом, а не минусом.
В чем основные отличия С++ от Java и С#:

Вам придется понять что такое указатель и ссылка. На самом деле это не сложно, если понять что такое адрес. Если сами не разберетесь, думаю на этом ресурсе вам помогут.
В С++ нет сборщика мусора поэтому память придется чистить в ручную с помощью delete
То есть нужно запомнить, если выделили память через new, то где-то дальше в в программе вы должны очистить ее с помощью delete.

Вот в принципе и все основные неудобства которые может вызвать С++ по сравнению с С# или Java. 
Теперь поговорим почему разработчики движков не часто используют C# или Java.
Вы упомянули про JIT. Как раз JIT компиляция проблем не создает а а даже может помоч
при оптимизации под конкретную архитектуру, увеличив производительность. Компилятор Clang (LLVM) как раз развивается в этом направлении.
Основным недостатком C# и Java, является сборщик мусора.
Сейчас объясню почему.
Игровой движок представляет из себя фактически бесконечный цикл, который должен выполнятс
30 раз в секунду, а лучше 60 или больше. А вот теперь представьте, что вы написали движо
который выдает 30 fps. Все работает, все круто. А затем пришел сборщик мусора. Чтоб
очистить память он должен остановить выполнение процесса (ну или хотя бы потока), та
как сборщик не может анализировать память которая изменяется. Что выйдет из такой приостановки программы сами можете догадаться. То есть в вашем движке живет что то, что пожирает ресурсы и периодически приостанавливает выполнение вашей программы. И самое страшное вы этим практически никак не можете управлять. Согласитесь это не приемлемо, если конечно у вас ресурсов не до фига.
К еще одному недостатку языков С# или Java можно отнести большее потребление памяти, что для игр также критично.
Исходя из этого тот же С# хорош для indie игр, и не пригоден для разработки серьезных движков.
Так что использование С++ в gemedev это не традиция, это скорее необходимость, та
как альтернативы нет. В любом случае С++ хороший язык, с богатыми возможностями, так что советую его изучить, если вы действительно собираетесь в будущем писать качественные движки.


Ответ 13

Специально для тех, кому не нравится вычленять информацию из ответа, а хочется голых фактов, пишу ещё один ответ.

TL;DR

Учите плюсы.

Длинная версия

Если у вас есть команда, то ваш выбор ограничен мейнстримовыми языками. Выбрать экзотически
язык могут себе позволить только инди-одиночки, а реально нуждаются в нём — те, кт
пишет алгоритмически сложные игры. Так как пересечение двух вышеописанных множеств пренебрежимо мало, то, вероятно, всех на самом деле интересует написание написание средненьких и инди-игр небольшой командой. Эрго, рассматриваем применимость мейнстримовых языков.


C++. Язык по умолчанию. Абсолютный рекордсмен по производительности, по кросс-платформенности
по совместимости со всем и вся, а также обладатель самого масштабного наследия кода
Плюсы кошмарны, несмотря на тщетные попытки запрятать указатели куда подальше, а текст ошибок сделать хоть немного вменяемым. Undefined behavior и прочие радости жизни никуда за столько лет не девались. Но язык обладает преимуществами, к которым остальные языки даже не приблизились.
Java. Язык популярен во многих сферах, в результате для него написано много библиотек
в том числе для игр. Производительность — плохая (в несколько раз медленнее плюсов н
математических тестах). Возможности для оптимизации очень ограничены. Несмотря на хорошую кросс-платформенность, портирование далеко не на все актуальные платформы будет безболезненным: забудьте про XBOX, виндофоны и прочие девайсы.
C#. Примерно на равных состязается с Java в энтерпрайзе, но сильно устапает по популярност
в опен-сорсе. Изначально производительность такая же плохая, как у джавы, но возможност
оптимизации значительно шире. Если при проседании производительности в джаве вам придётся переписывать критичные куски на другом языке, то в случае шарпа есть возможность уйти "на уровень ниже" в пределах языка.

Часть игровых движков с потрохами на плюсах позволяют писать код на шарпе. Если нагрузка на CPU позволяет расходовать ресурсы впустую, то можно использовать.

Совершаются попытки компилировать в нативный код, но это всё равно далеко не C+
по производительности: "управляемость" языка никуда не девается из-за компиляции, пусть и с компилятором на базе плюсового.
VB.NET. Как C#, только с меньшими возможностями для оптимизации и меньшим выбором библиотек. Преимуществ над C# не имеет — ну, кому-то может нравиться синтаксис.
JavaScript. Антирекордсмен по производительности, несмотря на попытки добавить хитроумны
оптимизирующие прибамбасы в браузеры. Жабоскрипт выбирают не от хорошей жизни, особенно в геймдеве. Собственно, если вы пишете для браузеров, особо выбора нет.

В браузерах всё медленнее минимум на порядок — не только исполнение кода, но и отрисовк
графики — тормозят даже простенькие инди-игры. Как способ оптимизации никто в здравом уме и трезвой памяти этот язык использовать не будет. Из достоинств — работает везде, где есть браузер.
Objective-C. И компиляторы, и язык — с сишными корнями. Уход на Obj-C сложно назват
уходом от страшного и ужасного си, так что выпадает из рассмотрения. Ну и Apple пытается запрятать морально устаревший язык под ковёр, выставив Swift — перспективы не лучшие (правда, только если смотреть далеко в будущее). Кросс-платформенность никакая.
Delphi. В новых версиях заявлена кросс-платформенность, так что можно рассмотреть
К сожалению, кросс-платформенность настолько тормозная, что приложение-пример падает из-за недостатка памяти. Собственно, всё.

Язык родственен C++, в последних версиях появились обобщённые типы и прочее, пр
этом в нём меньше мрака вроде undefined behavior. Однако и многих возможностей плюсов нет, а компилятор так и не приблизился по оптимизациям к плюсам.
Python, Ruby и иже. Главные конкуренты с жабаскриптом по тормознутости. Питон, написанны
на шарпе, питон, написанный на "почти питоне", и прочие подобные приблуды, пытаютс
выжать из языка сносную производительность, чтобы не было стыдно на фоне жабаскрипта, но до плюсов как до Луны пешком. Разумеется, как и для любого мейнстримового языка, имеется зоопарк библиотек-фреймворков, но кросс-платформенность ограничена.


Итог

Для "скриптовых" языков пишутся разнообразные оптимизаторы. Но динамическую типизаци
никуда не выкинешь, поэтому невозможно оптимизировать код, оставив его в первозданном виде. Иногда изобретаются подмножества языка, чтобы на них писать что-то более оптимизированное, но это ломает весь кайф, что называется.

В несколько более выигрышной позиции "управляемые" языки. Совершаются попытки врод
прикручивания плюсового компилятора, прикручивания LLVM, но управляемость остаётся на месте. Ну и в случае C# и то, и другое находятся на ранних стадиях развития, поэтому говорить о результатах рано.

Строго типизированные компилируемые языки без хитрых оптимизаций все слишком родственн
с плюсами, чтобы гордо заявить "я теперь не пишу на сях". Учитывая пропасть в кросс-платформенности и совместимости, переходить на них смысла нет.

Так или иначе, скомипилированный код всё равно оказывается быстрее, потому что JI
должен быть быстрым. Проект на плюсах, компилирующийся час — это нормально. Проект на другом языке, компилирующийся у игрока час — это ни в какие ворота.

На данный момент на горизонте не видать ничего, способного из мейнстримовых "несишных
языков выжать сишную производительность. Если упираетесь в CPU, и вы не один в команде, вариантов у вас нет.


Ответ 14

Для создания простенькой 2Д игры , можно учить скриптовые языки, а для красивой 3
игр, нужно конечно знать плюсы или C#. Есть множество игровых порталов которые рассказывают о создании игр, и один из них описал iwowa.


Ответ 15

Для managed DirectX под дотнет есть куча фреймворков - SharpDX, SlimDX, Tao Framework
связка какого-то из них и Unity3D по идее должна дать возможность вполне себе писать движки на шарпе.


Ответ 16

Есть ММО, точнее не игра а на текущий момент разработка на Blitz3D+C#. В сил некоторых обстоятельств название разглашать не могу.


Ответ 17

Игры можно писать на каком угодно языке, к примеру для питона существует неплохой фреймворк pyglet

Если нужно что то более серьезное рекомендую unity3d

Как вернуть удаленные компоненты в Windows Phone Framework?

Суть в том, что из многих компонентов в WinPhone Framework зачем-то удалили целые куски. Например, из System.Collections.Generic выкинут SortedSet (очевидно в Microsoft считают, что он там не нужен). Аналогичная ситуация по-моему с Bitmap, но там хотя бы можно заменить на WriteableBitmap Собственно вопрос: как можно впихнуть всю эту радость обратно. Ведь эти типы определенно не зависят от самой платформы, просто видимо желание левой пятки Microsoft обрезать фреймворк (зачем?). Я вижу два способа: Создать свой класс и нагло его описать. Сурово, будет работать, только один черт знает, как выглядит source code у того же SortedSet. Его можно где-то посмотреть? Пока нагуглить не смог. Впихнуть как нибудь компоненты из .Net framework нормального в WinPhone-проект. Насчет работоспособности этого что-то я не уверен. Еще есть пояснения, комментарии, предложения? Очень хотелось бы, чтобы кто-нибудь пояснил, можно ли найти исходный код для классов из .Net Framework. [update № раз] Жесть, чем дальше изучаю, тем больше поражаюсь идиотизму ребят из Мелкософта. Ну зачем, зачем надо было выкидывать метод RemoveAll из класса List? С RemoveAll я бы написал лямбда-выражение, тут наколдовал нечто с foreach: foreach (someType x in files) { if (statement) files.Remove(x); } Вместо RemoveAll(x=>y). Интересно, это правильно? З.Ы. Нет. По крайней мере не всегда. Обновлено 30 октября 2012. В общем, если кто-нибудь будет это искать, и, если кому надо, есть сторонняя библиотека "Prism" для Silverlight, где в разделе для Windows Phone есть dll-ка Microsoft.Practices.Prism.dll Там большинство выкинутого функционала. RemoveAll там по крайней мере точно есть.

Ответ

Его можно где-то посмотреть? С помощью .NET Reflector. Но учтите, что там могут быть обращения к неуправляемым библиотекам, отсутствующим в Windows Phone.

Можно ли удалить установленные SQL Server`ы, Visual C++, Net Framework?

В "Программы и компоненты" имеется несколько установленных версий Microsoft SQL Server (2005, 2008 Compact Edition, 2012 Express Local и т.п.). Можно ли удалить их и оставить к примеру только Microsoft SQL Server 2014?
Дополнение: Есть еще куча Microsoft Visual C++ 2005..2014 Redistributable (x86) - 10 - 14.0.23506 Можно их снести, а оставить только последнюю версию?
Тот же вопрос по отношению к .NET Framework

Ответ

Не стоит удалять ни .NET Framework, ни MSVC Redistributable.
Дело в том, что они не заменяют друг друга. Если программа требует Redistributable MS VC 2008, то она перестанет работать, когда вы его снесёте, даже если на машине будет старший Redistributable. Таким образом предотвращается DLL Hell: ситуация, когда программа не проверяет версию рантайма, с которой работает, и вылетает из-за бинарной несовместимости версий.

То же касается и фреймворка .NET, хотя здесь немного сложнее: некоторые версии можно сносить, некоторые нет, между ними существуют нетривиальные зависимости
MSDN: Выбор более старых версий
Версии .NET Framework 2.0, 3.0 и 3.5 построены на базе одной и той же версии среды CLR (CLR 2.0). Эти версии представляют последовательные уровни единой установки. Каждая версия построена на базе предыдущих версий. Невозможно запустить версии 2.0, 3.0 и 3.5 параллельно на одном компьютере. При установке версии 3.5 автоматически создаются уровни версий 2.0 и 3.0, и приложения, созданные для версий 2.0, 3.0 и 3.5, могут выполняться в версии 3.5. Однако в .NET Framework 4 этот принцип "слоев" закончился. Начиная с .NET Framework 4, разработчики могут использовать внутрипроцессное параллельное размещение для запуска нескольких версий среды CLR в одном процессе. Кроме того, если в приложении выбрана целевая платформа версии 2.0, 3.0 или 3.5, пользователям может потребоваться включить .NET Framework 3.5 на компьютере с Windows 8 или Windows 8.1, прежде чем они смогут запустить это приложение.
Из версий 4.x, старшие версии являются заменой младшим, так что по идее достаточно сохранить самую старшую из установленных версий (4.6.1 на текущий момент). Версия 3 и 3.5 являются по сути сервис-паками к версии 2, так что если они у вас есть, нужно оставлять и их, и версию 2.
Есть противоречивые сведения о том, стоит ли сносить младшие версии (1.1, 2, 3, 3.5), если у вас уже есть 4+. В теории они должны быть совместимы. Но я бы не рисковал, много места они не занимают.

Дополнение (по результатам обсуждения в чате и комментариях):
Начиная с Windows Server 2003, .NET 2.0 является частью системы, так что он не будет отображаться в списке установленных программ. То же относится к .NET 3.0, начиная с Vista/2008. Это значит, что вам из всего набора фреймворков 2.0, 3.0, 3.5 вам нужно иметь 3.5 (желательно SP1), при этом 2.0 SP2 и 3.0 SP2 у вас будут автоматически (и вы, судя по всему, не сможете их удалить).
С 4.х всё проще: вам нужен лишь последний фреймворк (на данный момент 4.6.1), инсталляция нового должна замещать предыдущий.
Для старинных версий 1.1 и 1.0: программа будет работать и при наличии 2.0, если только она не отконфигурирована на использование конкретной версии, и игнорирование старших версий. То есть, в большинстве случаем удалять их можно, с минимальным риском. Но если рисковать не хочется, можно и оставить.
Дополнение В Windows 10 уже изначально стоит Net framework 2.0, 3.0, 3.5, 4.0
Статья, как проверить установленные версии: Практическое руководство.Определение установленных версий платформы .NET Framework

Теоретически, можно удалять версии, если вы точно знаете, что они не нужны ни одной из программ на вашей машине. Но это по сути задание не для человека, а для системы управления зависимостями. Лучше неё с задачей никто не справится.