Кошмар слияния платформы объекта

Question

Кошмар слияния платформы объекта

Вы неправильно настраиваете прослушиватель щелчков на кнопках, вы их вкладываете. Вы должны сделать следующее -

public class MainActivity extends AppCompatActivity {
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            final Button button = findViewById(R.id.btn);
            final Button button1 = findViewById(R.id.button2);
            final Button button3 = findViewById(R.id.button3);
            final TextView textView = findViewById(R.id.tex);
            final EditText et1 = findViewById(R.id.et1);
            final EditText et2 = findViewById(R.id.et2);
            final Button button4 = findViewById(R.id.button4);
            button4.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View arg0) {
                    et1.setText("0");
                    et2.setText("0");
                }
            });

            button1.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View arg0) {
                    textView.setVisibility(View.VISIBLE);
                    Toast.makeText(getApplicationContext(), "done", Toast.LENGTH_SHORT).show();
                }
            });

            button.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View arg0) {
                    Toast.makeText(getApplicationContext(), "done", Toast.LENGTH_SHORT).show();
                }
            });
            button3.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View arg0) {
                    String value = et1.getText().toString();
                    int n11 = Integer.parseInt(value);

                    String value2 = et2.getText().toString();
                    int n22 = Integer.parseInt(value2);
                    textView.setText(String.valueOf(n22 + n11));
                    Toast.makeText(getApplicationContext(), "done    ", Toast.LENGTH_SHORT).show();


                }
            });
        }
    }

29

edmx merge tfs version-control entity-framework

задан Alexandre 30 October 2019 в 06:34

3 ответа

Другие вопросы по тегам:

edmx merge tfs version-control entity-framework

Похожие вопросы:

score 3 · Answer 1

Как вы сказали, одним из вариантов является блокировка файла.

Другой возможный вариант - направить все изменения модели через одного человека в команде.

Другой вариант - разбить файл на более мелкие файлы (например, по одному на класс), возможно, оставив позади некоторую поддержку дизайнера.

Другим вариантом является создание собственного процесса, потенциально использующего XSLT для преобразования файла EDMX, но я не уверен, как именно это будет выглядеть, файл designer.cs является огромным трудным для объединения.

Другой вариант - рассмотреть другой ORM.

Я не уверен, что они делают что-то, чтобы улучшить это в следующей версии EF. Сброс такого большого количества данных в один файл не подразумевает масштабируемость любого рода (но LinqToSql делает то же самое - в этом случае Дэмиен Гард создал несколько шаблонов T4, чтобы разбить файл на части, не уверенный, существует ли что-то подобное для EF).

score 1 · Answer 2

Я не очень знаком с EF, в частности, но у меня было немало проблем с ультра многословным & amp; хрупкий сгенерированный код. В каждом случае лучший ответ о том, как объединить это, было «не надо». В вашем сценарии это, вероятно, означает одно из двух:

1) Уточните модель продвижения кода, чтобы код EF двигался только в одном направлении. Другими словами, каждый конфликт будет разрешен либо как «копия из исходной ветви» (AcceptTheirs), либо как «сохранить цель неизменной» (AcceptYours), и каждый должен знать, что есть что заранее. Чаще всего вам понадобится AcceptTheirs при продвижении недавно протестированного кода в направлении стабильных узлов дерева ветвей и AcceptYours при объединении исправлений обратно в нестабильные ветки / ветки разработки. (Если есть> 1 ветка разработки, вам нужно разделить вещи так, чтобы только код EF, принадлежащий команде, работающей в данной ветке, следовал последнему правилу. Все, что они не изменяют намеренно, должно быть перезаписано кодом других команд вытекает из ветви интеграции, используя AcceptTheirs, если необходимо.)

               /- [...]
               /- v1.1
          /- Release

    + Integration
          - Dev1
          - Dev2
          - [...]

" Объединить, скопировать "

2) Буквально не объединять их; полностью исключить код EF из процесса. Когда для интеграции ветвей требуются изменения в базе данных и / или ORM, заново создайте прокси-классы непосредственно из базы данных. (конечно, после разрешения + построения любых конфликтующих изменений в ваших файлах SQL) Экстремальная версия: делайте это при каждой автоматической сборке, а не только при слиянии.

score 5 · Answer 3

В этой статье описаны некоторые стратегии работы с большими моделями Entity Framework. Вы можете подумать об их использовании. Однако я обнаружил, что большая часть проблем с регенерацией EDMX возникает из-за изменений, внесенных путем перетаскивания в конструкторе графического интерфейса. С другой стороны, обновление модели из базы данных или через окно свойств имеет тенденцию вносить изменения довольно разумным образом, и их не сложно объединить.

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

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