Евгений

SELECT t1.image AS image1 ,t2.image AS image2 ...

Советую почитать Pro ASP.NET Core MVC 2

МИФИ, там целый факультет.

Так храните где-нибудь состояние... Local Storage, например.

Вы же делаете инъекцию сервиса Trustlet в два компонента. Каждый раз создается отдельный инстанс сервиса, где тот самый список инициализируется двумя элементами:

public trustlets:Array<Trustlet> = [                   // mock !!
    { name: 'Trustlet1', repo: 'Repository1' },
    { name: 'Trustlet2', repo: 'Repository2' }
  ];

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

Модели предпочитаю делить на доменные(то, что мапится к БД) и модели представления(то, что нужно отдать клиенту). Реляционная модель данных в большинстве случаев не кореллирует с моделью представления(в вашем случае, например, списки категорий и пр.)

Наследование же представления от домена, на мой взгляд, абсолютно имеет место быть для систем без сложной бизнес-логики (там, где просто CRUD - можно вообще без моделей представления обойтись); в ином случае можно закончить тем, что будет несколько уровней наследования в погоне за требуемым классом. И каждое изменение такого класса(особенно, если он родительский) может стать головной болью.

Обычно, использую такую декомпозицию слоев приложения:
View -> Controller <-Service <- Repository <- Database

Уровень Repository оперирует доменом, уровень Service оперирует как доменом, так и представлением, уровень Controller - только представлением. Соответсвенно, в уровне сервисов и производится преобразование домена в представление.

Ух ты, даже готовые классы, чтобы меньше писать? Ну хоть на этом спасибо ))

p/s есть готовые классы - используй Code-First подход. Не нужно никаких Raw Sql команд.

Для EF:
https://msdn.microsoft.com/en-us/library/jj193542(...
https://metanit.com/sharp/entityframework/1.2.php

Для EF Core
https://docs.microsoft.com/en-us/ef/core/get-start...

Системный аналитик/инженер -> системный архитектор.

Суть TDD "на пальцах":
1. Написать тест на проектируемый кусок кода.
2. С успехом "провалить" этот тест.
3. Написать достаточно кода, чтобы пройти тест успешно.
4. Отрефакторить получившийся код.

И дальше все начинается сначала. Чтобы понять как это работает, предлагаю загуглить решение задачи FizzBuzz с применением TDD(на YouTube роликов полно, постов в блогах не меньше).

Дальше можно уже почитать литературу по тестированию. Я бы посоветовал сначала что-то фундаментальное по теме тестов, например, The Art of the Unit Testing. Дело в том, что TDD это в первую очередь и одновременно "всего лишь" техника написания кода через тесты. И чтобы ее успешно применять, надо уметь писать эти самые тесты.

В этой книге найдёте много полезного про тесты и их концепцию. Советы по TDD также присутствуют.

Ну вот, например, самое первое видео по релевантному запросу в youtube ведет к этому плэйлисту.
Не смотрел, но судя по комментариям и соотношению like/dislike контент людям нравится. Последнее видео загружено недавно.

p/s речь у ведущего норм :)

using Newtonsoft.Json;
...
var result = JsonConvert.DeserializeObject<T>(json);

Где T - класс, представляющий ваш объект JSON; json - собственно, строка JSON- формата на входе, которую нужно представить в виде объекта.

p/s Любезно воспользовался источником на stackoverflow. Это было быстрее, чем написать приведенный выше код :)))

p/p/s Объект, запрошенный в качестве примера, будет выглядеть так:

class MyClass
{
    public int Response { get;set; }
}

Никак. Why?
Можно восстановить детали по логам, тем же e-mail нотификациям и так далее.

Хранить ФИО в таком формате: [X]Фамилия[X]Имя[X]Отчество, где [X] - некий спец. символ, например пробел. Ну или любой другой, главное избежать конфликтов с этим символом, чтобы он не участвовал в образовании самого текста ФИО.

Это позволит делать LIKE '[X]'+'substring' - что будет отрабатывать по началу имени, фамилии или отчеству(substring - подстрока поиска).

P.S. возможно стоит и посмотреть в сторону нормализации и разбить ФИО - все зависит от того как в системе вопринимается сущность. Если это не атомарное значение в концепции Вашей системы, если Вам нужно хранить большие объемы ФИО с историей изменения, например, то здесь Имя, Фамилия и Отчество это отдельные свойства сущности.