Где лучше в MVVM реализовать дополнительную логику?

@JeyCi · Регистрация: 29.06.2019

Студворк — интернет-сервис помощи студентам

Комментарий модератора

Тема создана разделением темы Привязка DP-свойства UserControl к вложенному элементу

Сообщение от Элд Хасп

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

так оно (заданный Result) ведь всегда может быть перезадано? или я ошибаюсь... переназначить свойство - это же не удалить/создать объект заново...

мне почему-то кажется, что это не проблема, а как раз и задумано было, чтобы можно было переназначать свойства в зависимости от нужного (например, цвет текста при value>1000, условно говоря) - вот и вынесли это DP в отдельный класс... а за пример реализации и использования в XAML - спасибо!..

? только в каких случаях это DP подключают обычно?.. как по мне, так Styles и Templates и даже Converters - нормальные внутренние (для объекта) свойства, дальше которых уже и придумать нечего (с практической точки зрения) чтобы захотеть подключать из-вне класса ещё и DP за гранью всего, что можно задать и в объекте...

@Элд Хасп · 13.10.2025, 02:54

Сообщение от JeyCi

не вписывается это (асинхронная загрузка файлов) в Binding у меня пока что

Не видя кода - подсказать не смогу.
В WPF Binding работает с INotifyProptrtyChanged.PropertyChanged из любого потока. Маршалинга в UI поток не требуется.
А вот для коллекций и события команд - нужен маршалинг в UI поток.

А в UWP наоборот. Для PropertyChanged нужен маршалинг, а для коллекций и команд - нет.

Почему так сделали... Да хрен его знает. По пьяне, наверное. Никак объяснений этому я не находил и в голову мне не приходят.

Добавлено через 13 минут

Сообщение от JeyCi

EF (которую все почему-то невзлюбили)

Почему все?
Я часто использую. И предпочитаю пред другими методами работы с БД.

Сообщение от JeyCi

1) в IRepositary - нужные действия с db

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

Сообщение от JeyCi

отдельно Update - в public class CreditApplicationRepository : Repository<CreditApplication>, ICreditApplicationRepository - т.к.

Абсурд.
Никакого смыла отдельно под Update делать два интерфейса - нет.

@Andrey-MSK · 13.10.2025, 08:53

Сообщение от JeyCi

Пример Архитектуры (по линку - один ниже для всего) про Repositary, EF (которую все почему-то невзлюбили), Model и т.д.:

Вы в теме про WPF, зачем вы показываете другую технологию? Да ещё и сами всё больше запутываетесь...
DI в Desktop делается в несколько строк...

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Импортируем нужные пакеты для DI
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
 
// Класс приложения
public partial class App : Application
{
    // Свойства для DI
    public IServiceProvider Services { get; }
    public IConfiguration Configuration { get; }
    // Экземпляр приложения
    public static new App Current => (App)Application.Current;
 
    public App()
    {
        // Подключаем свойства для DI
        Configuration = GetConfiguration();
        Services = ConfigureServices();
 
        InitializeComponent();
    }
    // Получаем конфигурацию приложения
    private static IConfiguration GetConfiguration()
    {
        IConfigurationBuilder builder = new ConfigurationBuilder()
            .SetBasePath(AppDomain.CurrentDomain.BaseDirectory)
            .AddJsonFile("appsettings.json");
 
        return builder.Build();
    }
    // Запускаем сервисы
    private static ServiceProvider ConfigureServices()
    {
        ServiceCollection services = new ServiceCollection();
 
        services
            .AddSingleton(Current.Configuration)
            .AddSingleton<IMainDA, MainDA>()
            // ...
    }
}

И потом этим пользуемся в любом месте приложения...

@Andrey-MSK · 13.10.2025, 10:23

JeyCi, По поводу интерфейсов, я вообще их вынес все в отдельную сборку, которая не зависит от платформы...
Название: Services.png
Просмотров: 133

Размер: 7.3 Кб

Название: Services.png
Просмотров: 133

Размер: 7.3 Кб

@Элд Хасп · 13.10.2025, 12:24

Сообщение от Andrey-MSK

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

Согласен.
Иначе вообще теряется смысл их использования.

@generis · 13.10.2025, 14:52

Сообщение от Элд Хасп

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

Сообщение от Элд Хасп

Абсурд.

Не всегда.
В отличие от C++ в C# интерфейсы это единственная возможность множественного наследования.

@Элд Хасп · 13.10.2025, 15:01

Сообщение от generis

в C# интерфейсы это единственная возможность множественного наследования.

А зачем это нужно, если реализация неотделима от интерфейса и эта реализация в единственном числе?

@Andrey-MSK · 13.10.2025, 15:01

Сообщение от generis

В отличие от C++ в C# интерфейсы это единственная возможность множественного наследования.

Имеется ввиду один разработчик сделал интерфейс и работаем с ним, в нём описано всё что нужно для работы этого слоя приложения, а другой под этот интерфейс пишет реализацию, и их может гораздо больше чем одна (пример IDbCommand - этот интерфейс реализуют классы доступа для MS SQL Server, MySQL, PostgreeSQL, SQLite), и располагается это всё в разных сборках. И эту реализацию можно подменить в любой момент, а основное приложение этого даже и не заметит.

@generis · 13.10.2025, 15:16

Сообщение от Элд Хасп

А зачем это нужно, если...

"если" бывает много, всех и не сосчитать.

Не по теме:

Сообщение от Andrey-MSK

Имеется ввиду один разработчик сделал интерфейс и работаем с ним, в нём описано всё что нужно для работы этого слоя приложения, а другой под этот интерфейс пишет реализацию, и их может гораздо больше чем одна (пример IDbCommand - этот интерфейс реализуют классы доступа для MS SQL Server, MySQL, PostgreeSQL, SQLite), и располагается это всё в разных сборках. И эту реализацию можно подменить в любой момент, а основное приложение этого даже и не заметит.

Если все написать в рифму, то получиться поэма.

@Элд Хасп · 13.10.2025, 15:42

Сообщение от generis

"если" бывает много, всех и не сосчитать.

Ну, не знаю.
Мне в голову не приходит в каких обстоятельствах может понадобится подобное.
Только один аргумент в голову приходит "А чтобы было!"

@generis · 13.10.2025, 17:15

Элд Хасп,
Мы зацепились не о конкретном примере, а о методике где действует принцип - никогда не говори никогда.
У всех опыт ограничен и не известно, что вылезет на будущее.

@wizard41 · 13.10.2025, 17:25

Сообщение от generis

опыт ограничен и не известно

Тем не менее, в части использования интерфейсов (и их нужности) Элд Хасп заметил совершенно верно - зачем он нужен в данном случае?

Сообщение от generis

что вылезет на будущее

Того точно так же поправят - убери интерфейс, он здесь не нужен.

@JeyCi · 13.10.2025, 21:22 **[ТС]**

Сообщение от Andrey-MSK

зачем вы показываете другую технологию?

чтобы после написания проекта для WPF - спокойненько расширять на ASP.NET (для вэб), что вряд ли, но всё-таки... в своё время устала переписывать код и теперь, действительно, Dependency Inversion из S.O.L.I.D -- надо как-то (как вы все описываете) всё-таки начать использовать... чтобы только не рефакторить потом... спасибо за очень ценные советы!

... (но не люблю сильно наращивать код, поэтому отвечаю медленно)... кстати в EF уже пока и не хочу лезть - попробую обойтись DTO (тоже пример)... потом, может внедрю...

Сообщение от Элд Хасп

Весь смысл интерфейсов - это абстракция от реализации, слабые связи между проектами (сборками).
А здесь в одной сборке и интерфейс, и его реализация. На фига тогда интерфейс вообще нужен? Просто "а что бы было!" ?

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

Сообщение от Элд Хасп

А зачем это нужно, если реализация неотделима от интерфейса и эта реализация в единственном числе?

+1 не спешу сильно много абстракций создавать... в принципе и классами можно обойтись на начальном этапе... интерфейсы потом если надо можно дописать... (но всё-таки лучше иметь в виду)

Сообщение от generis

В отличие от C++ в C# интерфейсы это единственная возможность множественного наследования.

+1

Добавлено через 56 минут

Сообщение от Элд Хасп

не вписывается это (асинхронная загрузка файлов) в Binding у меня пока что
Не видя кода - подсказать не смогу.

- пока с CancelationToken и Exceptions не разберусь из Task'ов - даже пробовать не буду binding в WPF - но, наверно, это то, где будет задействовано ваше CanExecuteChanged для LongRunTasks (в threadpool'e)... мне самой не нравится такое тз (думаю, как упростить хотя бы до одного Task и в AsyncRelayCommand - но тогда, действительно, будет LongRunTask.. да и ProgressBar нужен будет как-то на такое, вероятно)...... а вообще, это здорово, что Factory позволяет создать много clients (как здесь)

@Элд Хасп · 14.10.2025, 00:03

Сообщение от JeyCi

пока с CancelationToken и Exceptions не разберусь из Task'ов - даже пробовать не буду binding в WPF

А при чём здесь биндинги?
Это уровень Модели.
Максимум что может быть в VM - это перехват исключений и прокидывание их в какой-то канал уведомлений.
Откуда уже View быть их показывать пользователю.

Bindig же это всего лишь удобный способ задания связи между свойством UI элемента и свойством источника (в данном контексте - свойством ViewModel).

Добавлено через 27 минут

Сообщение от JeyCi

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

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

Мой совет, пока нет опыта, не пытайтесь "экономить" на количестве сборок (проектов).

Конкретно в данном случае, просто непонятно зачем нужны эти три интерфейса: IRepository<T>, ICreditApplicationRepository и IUnitOfWork.

Даже если мы делаем в одной сборке, но "с прицелом" на абстракцию, то интерфейс ICreditApplicationRepository - совершенно лишний.

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

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
    // Три интерфейса с абсолютной абстракцией
    public interface IReadRepository<T> where T : class
    {
        // Методы получения значений: Get...
    }
 
 
    public interface IRepository<T> : IReadRepository<T> where T : class
    {
        // Методы изменений значений: Add, Remove, Update
    }
 
    public interface IUnitOfWork : IDisposable
    {
        // Методы управления транзакцией и сохранением
        void BeginTransaction();
        void CommitTransaction();
        void RollbackTransaction();
        void Save();
    }

C#
1
2
3
4
5
6
7
8
    // Один интерфейс уже специфичный для предметной области задания
    public interface ICreditUnitOfWork : IUnitOfWork
    {
        // Члены нужные для работы конкретно с нашей БД
        IRepository<CreditEntity> Credits {get;} 
        IRepository<ClientEntity> Clients {get;} 
        IReadRepository<CurrencyEntity> Currencies {get;} 
    }

Все эти интерфейсы должны быть рассчитаны на сборку типа Standard 2.0

@Wolfdp · 15.10.2025, 02:29

Сообщение от Элд Хасп

Ну, не знаю.
Мне в голову не приходит в каких обстоятельствах может понадобится подобное.
Только один аргумент в голову приходит "А чтобы было!"

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

- мне нужно накатать "здесь и сейчас" небольшое приложение, код в будущем править рефакторить никто не будет. Значит юзаю static и DI тоже делаю через явные реализации. Интерфейсы применяю только там где они реально решают задачу множественного наследования.
- я хочу написать что-то большое и/или в долгую (буду сопровождать). Ну или банально покрыть тестами. Можно позволить себе расписать по нормальному, а в DI использовать интерфейсы.

Далее когда я зафиксировал одни из этих подходов (ну или придумал ещё какой-то), то просто следую ему. И пофиг нужен ли там интерфейс, или он избыточен -- есть общая архитектура. Это позволяет в моменте вообще не заморачиваться с тем "а как оформить код" и просто строчить. А то что нужно добавить новый файл с интерфейсом... ну это задача на пару секунд.

Сообщение от Элд Хасп

Абсурд.
Никакого смыла отдельно под Update делать два интерфейса - нет.

Хз, норм практика, когда у тебя есть общий репозиторий умеющий CRUD, и нужно его расширять уникальными действиями. Грубо говоря я хочу уметь создавать инвойс из разных источников данных, где разные наборы, типы и возможно даже зависимости.

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

@Элд Хасп · 15.10.2025, 11:08

Сообщение от Wolfdp

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

Во...во...
Тем более никаких уникальных действий здесь не нужно априори.
Я показал пример выше.
Три Интерфейса общего применения: IReadRepository<T>, IRepository<T>, IUnitOfWork.
И один интерфейс уже специфичный для предметной области: ICreditUnitOfWork.

В примере же из GitHub.
Один общий интерфейс: IRepository<T>
И два специфичных: ICreditApplicationRepository, IUnitOfWork.

Сообщение от Wolfdp

Проще писать по универсальному шаблону на все (почти) случаи, чем каждый раз угадывать "понадобиться мне это в будущем или нет".

Это если есть хорошее понимание и опыт реализации.
Я, например, тоже часто начинаю MVVM в одной сборке. Бывает и не разделяю его потом.
Но я понимаю зоны ответственности каждого слоя и они у меня не путаются даже в одной проекте.

А вот если опыта мало, если есть риск не уследить за "прониканием сквозь границы", то лучше, даже в простых случаях, делать сразу все слои изолированно по разным проектам.
И у ТС, на мой взгляд, именно такой случай.

@JeyCi · 16.10.2025, 22:22 **[ТС]**

вот, что меня насторожило в своё время - здесь - :

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

конкретно для myDbContext:
- вот конкретно для моего случая (sqlite или LocalDB - write_Only_One_User), может быть using (myDbContext cntx = new myDbContext()) { .. doSomething.. } достаточно? - чем D.I. может быть более выигрышным по сравнению с простой обёрткой using scope'a вставленного в контекст async Task в однопоточном App ?? ... я вообще всегда думала, что Service's только с URL'ов или с back-end'a подключаются... или это только для разрешения зависимостей во время компиляции можно использовать, а в run-time динамически без подключения к тому же Azure или др (только если localhost), app на Win10, -- особо и неоткуда подключать зависимости...

кстати там же - (та ветка с акцентом на EF по архитектуре слоёв тоже опирается на SOLID неплохо! )

"Сущности EF'а" - есть описание схемы хранения в базе данных, а не бизнес-модели. В идеале, они вообще не должны торчать из DAL. Эти сущности нужны только для того, чтобы можно было описать LINQ-запрос по которому EF вам SQL сгенерирует.

- упускала это из виду иногда, думая лишь о своих CRUD-задачах

@Wolfdp · 16.10.2025, 23:35

Сообщение от JeyCi

чем D.I. может быть более выигрышным по сравнению с простой обёрткой using scope'a вставленного в контекст async Task в однопоточном App

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

1. убрать зависимость от new. Допустим у нас класс для работы с БД. Инициализация его экземпляра потребует откуда-то вычитать тот же ConnectionString. Т.е. мы уже не можем просто пнуть new, нам нужно сначала сделать ReadConfiguration, который может вообще правится прям в рантайме (скажем юзер может указать источник конфигураций: локальный файл или вообще облако).

Тут и приходим что делать new Repository(connectionString) внутри Service не удобно, и гораздо лучше передать этот самый Repostiroy через конструктор или свойства.

2. убрать зависимость от логики инициализации объектов.

Если мы делаем new внутри класса, мы всегда создаем новый объект. А если нам вдруг понадобиться singleton -- поздравляем, мы идем править ВСЕ классы, где оно используется. DI подразумевает что мы поправим только верхнюю логику (которая обычно выражается в ioc контейнерах). Это гораздо гибче, чем зашитая внутри логика и позволяет лишний раз не править класс, в зависимости от того кем и как он используется.

3. класс становится проще.

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

Сообщение от JeyCi

"Сущности EF'а" - есть описание схемы хранения в базе данных, а не бизнес-модели. В идеале, они вообще не должны торчать из DAL. Эти сущности нужны только для того, чтобы можно было описать LINQ-запрос по которому EF вам SQL сгенерирует.

Ну это где-то в идеальном мире.

Не по теме:

Я сталкивался когда на проекте практиковали одну(!) модель на всё, начиная от БД и заканчивая тем что попадёт в ViewModel. Вроде суицидов не наблюдал.

Тут скорее нужно понять идею что "формат хранения" != "бизнес модель". Допустим такая ситуация:
- пользователь в логике приложения выражен как User. Эта модель используется повсюду.
- у User есть Balance, который меняется по каждому чиху. Т.е. это настолько нагруженные данные, что их нужно максимально закешировать по максимум.
- также у User 100500 полей, которые меняются раз в никогда.
- итого для БД логично создать две отдельные таблицы 1к1: User и UserBalance. При вычитке мы делаем запрос к обеим. При правке баланса -- только ко второй.

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

@Элд Хасп · 17.10.2025, 01:40

Сообщение от JeyCi

"Сущности EF'а" - есть описание схемы хранения в базе данных, а не бизнес-модели. В идеале, они вообще не должны торчать из DAL. Эти сущности нужны только для того, чтобы можно было описать LINQ-запрос по которому EF вам SQL сгенерирует.

Зависит от того как они объявлены и используются.
1) Сущности с мутабельными свойствами, с атрибутами управления схемой БД, создаваемые и отслеживаемые долгоживущим контекстом - такие сущности лучше инкапсулировать в репозитории.
2) Сущности со свойствами только для чтения, без атрибутов, схема БД задаётся в контексте, создаются "одноразовым" контекстом (и следовательно не отслеживаются) - такие сущности это обычные DTO, которые могут безопасно "путешествовать" по любым слоям.

Добавлено через 6 минут
Во многом споры вокруг EF из-за слишком многофункциональной его реализации.
Он и запросы парсит, и локальный кеш поддерживает, и сущности отслеживает, и даже DTO только для чтения может изменять и многое другое.
Это его божественность и создаёт большие риски для безопасности.
Поэтому если репозиторий реализуется по "недружественной" схеме, то всё "лишние хвосты" EF надо инкапсулировать в репозитории.

@JeyCi · 17.10.2025, 11:35 **[ТС]**

Сообщение от Wolfdp

и гораздо лучше передать этот самый Repostiroy через конструктор или свойства.

да, в с++ эта идея мне в своё время очень помогла...

Сообщение от Wolfdp

- указываешь в конструкторе нужные тебе классы/интерфейсы и закидываешь их в поля.

я в методы когда начинала закидывать, а override (нужный) до того не сделаю, то тут и начиналась очень неприятная правка "логики"... +1 принимается намёк на интерфейсы...

********************

Сообщение от Wolfdp

пока не начинают вылезать различия хранения, логики и отображения.

да, про БД 1к1 и про LazyLoading в EF, - явно скажется на скорости, если "хранение-логику" не разделить (классика SQL для скорости: конечно join, чем select из select'a) ...

и если "логику - view" не разделить, то закопаться можно в попытке описывать логику в контролах (частая ошибка начинающих)... благо, в WPF между логикой и view ещё есть VM (тут всю валидацию можно сделать, которую не делает сама бд)

******************** НО ВЕДЬ ВСЕГДА ГЛАВНЫЙ ВОПРОС: СКОРОСТЬ ~ РЕСУРСЫ
я там скорее цитировала про кэш (для десктоп) - не совсем понятен скепсис автора линка по отношению к использованию D.I. в desktop App ??

Сообщение от Usaga

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

@Andrey-MSK · 17.10.2025, 12:46

Сообщение от JeyCi

не совсем понятен скепсис автора линка по отношению к использованию D.I. в desktop App

Имеется ввиду потребление памяти. Когда сервис EF запущен через DI с параметром Transient или Singleton, а окно долгое время не закрывается и идёт интенсивная работа с БД, то кэш EF начинает расти... А в WEB сервис вызывается по Transient и работает до закрытия соединения, когда соединение закрывается, сервис уничтожается со всеми своими временными данными, потому кэш не успевает забиться...

Добавлено через 2 минуты
Потому в EF принято создавать DbContext перед использованием через using. Тогда кэш не будет сохраняться.

Добавлено через 11 минут
JeyCi,

Сообщение от Andrey-MSK

создавать DbContext перед использованием через using

То бишь DbContext не пробрасывается в DI, а работает только в методах репозитория, а в DI пробрасывается сам репозиторий.
Что-то типа такого

C#
1
2
3
4
5
6
7
8
9
using (UserStoreModel db = new UserStoreModel())
{
    Phone p1 = new Phone { NameP = "Samsung Galaxy S7", Price = 20000 };
    Phone p2 = new Phone { NameP = "iPhone 7", Price = 28000 };
 
    db.Phones.Add(p1);
    db.Phones.Add(p2);
    db.SaveChanges();
} // Тут контекста уже нет

Добавлено через 7 минут

Сообщение от Andrey-MSK

Тогда кэш не будет сохраняться.

Если он не нужен... А если нужен, то очистка памяти ложится на плечи разработчика...

Новые блоги и статьи Все статьи Все блоги /
мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .	[EasyBuilder Pro] Памятка по разработке для панелей Weintek ФедосеевПавел 26.08.2026 Памятка по разработке для панелей Weintek ВВЕДЕНИЕ Ранее, при реализации проектов основное внимание уделял разработке управляющей программы для контроллера, а панели оператора доставалось время. . .
Модель по догадкам anaschu 25.08.2026 Прошло две недели. Я уже рассказывал, как разговаривал с сотрудниками у сортировки и как понял, что главная ветка — не про приёмку, а про отбор. Но тогда я думал, что понял механику. На этой неделе я. . .	Запись в регистр сведений независимо от заполненности табличной части Maks 25.08.2026 Реализация из решения ниже выполнена на нетиповом документе с несколькими табличными частями, разработанного в КА2. Задача: Обеспечить запись документа в регистр сведений независимо от. . .	Ноутбук Альфария kumehtar 24.08.2026 Встретился тут в сети ноутбук Альфария, примарха Альфа-Легиона. Хотя возможно, это ноутбук Омегона, разумеется. Ну как вам?	Мастера простых решений DevAlt 23.08.2026 В сишарп стэках winforms, да и wpf существует сложная система связывания источниках данных и элементов формы(текстовые поля и метки), опирается все это на технологию событий и мета. . .

@Andrey-MSK 3392 / 2278 / 388 Регистрация: 14.08.2018 Сообщений: 7,719 Записей в блоге: 4
	13.10.2025, 10:23
	JeyCi, По поводу интерфейсов, я вообще их вынес все в отдельную сборку, которая не зависит от платформы... 1

@generis 9 / 7 / 2 Регистрация: 26.08.2025 Сообщений: 17
	13.10.2025, 17:15
	Элд Хасп, Мы зацепились не о конкретном примере, а о методике где действует принцип - никогда не говори никогда. У всех опыт ограничен и не известно, что вылезет на будущее. 0