simply_user так а что об этом читать-то?) Контролы WPF могут привязываться почти к чему угодно. Однако, чтобы они ловили изменения свойств привязанного объекта, нужно чтобы этот объект реализовывал INotifyPropertyChanged. По аналогии, коллекции должны реализовывать INotifyCollectionChanged. Всё. Все остальное - это уже программисту решать. Можно следовать паттерну MVVM до конца, можно где-то его нарушать - например, в случае неизменяемого объекта ИМХО это допустимо. Что называть моделью и вьюмоделью - это вам решать. Под "гибридом" я понимаю тот случай, когда вы не вводите отдельные классы для модели и для вьюмодели, а используете саму модель в привязке, и не более того.
simply_user можно конечно, только, очевидно, модель должна быть иммутабельной. Иначе придётся реализовывать INotifyPropertyChanged, что автоматически превратит модель в гибрид модели и вьюмодели.
simply_user всё, я наконец понял что вы имеете в виду, это коллекция файлов. Я почему-то подумал, что коллекцией вы называете список свойств ОДНОГО конкретного файла.
BadCats у вас тут живая дискуссия, не успел ответить)
Под "интерфейсом" здесь я понимаю НЕ интерфейс в терминах языка C# (которые interface), а "интерфейс" в широком смысле - т.е. некоторый контракт между сущностью и её пользователем.
Под интерфейсом к полю/делегату я понимаю пары методов, которые сгенерирует вам компилятор, когда вы напишете свойство или событие. Свойство это по сути синтаксический сахар, который превращается в пару методов get_ИмяСвойства и set_ИмяСвойства, плюс еще добавляется метаинформация о том, что эта пара методов - это свойство (чтобы отличить такую ситуацию от ситуации, когда вы сами напишите в коде два таких метода). Реализуя свойство, вы можете пользоваться (а можете и НЕ пользоваться) некоторым полем, чтобы хранить в нём значение свойства как есть, или в каком-то преобразованном виде. Код внутри get/set - это, условно говоря, преобразование между значением поля и значением свойства. Также, начиная с C# 3.0 вы можете создавать автосвойства с помощью синтаксиса {get; set; }, и компилятор автоматически сгенерирует вам поле для хранения значения.
Аналогичная ситуация с событиями. Тот синтаксис, что вы привели в вопросе ( public event EventDelegate myEvent = null; ) - это аналог автосвойства - делегат и событие к нему у вас объявлены одновременно. Однако вы можете воспользоваться и таким синтаксисом: https://msdn.microsoft.com/en-us/library/bb882534.aspx - это всё равно что явно реализовать get { .... } и set { .... } для свойства, не используя автогенерацию.
Oxoron самое главное-то не сказал) Можно принюгеть в примеры, но тогда вам (и тому, кто скачает исходники библиотеки) будет сложнее модифицировать библиотеку, т.к. примеры будут запускаться с релизной версией библиотеки из Нюгета. Так что как по мне лучше примеры (и тем более - тесты, иначе в них нет смысла) линковать к основному проекту/проектам в "src" через обычные проектные зависимости, которые управляются Студией. Я обычно собираю всё в один солюшен, и просто ставлю зависимости.
den11770 тогда проверьте, что у ВАС стоит наиболее свежая версия версия нужного вам райнтайма (наиболее свежая в рамках одной версии тулсета, т.е. версия именно 10-го рантайма), и возьмите его из своей системы (оттуда, откуда показывает DepWalk), положите рядом с exe и так и распространяйте. Убедитесь, что после того, как вы положите dll-ку рядом с exe, DepWalk будет подтягивать именно её при поиске зависимостей. Это будет доп. гарантией того, что и Винда на целевом компьютере также подтянет именно рядом лежащую dll.
Oxoron стандартная структура репы для проектов на C#/F#, которой я сейчас стараюсь придерживаться:
/docs - документация
/examples - проекты/проект с примерами использования библиотеки. Либо один проект с несколькими файлами кода, если примеры простые, либо, если примеры достаточно объемные, отдельные проекты в подпапках
/src - основной исходный код, "мясо" библиотеки. Также подпапки для проектов.
/tests - тесты, структура аналогична примерам.
Обратите внимание, что если тесты - это скорее для разработчиков библиотеки, и тех, кто уже хорошо с ней знаком и интересуется деталями и качеством реализации, то примеры - это эдакая презентация библиотеки. Если в тестах вы должны добиваться максимального покрытия, то примеры должны показывать наиболее частые и/или наиболее интересные юзкейсы для вашей библиотеки. Начиная с самых простых, по которым можно оценить, насколько просто начать работать с библиотекой, заканчивая наиболее хитрыми, где показываются достоинства вашего решения. Можно сравнить с другими реализациями, если таковые есть.
k-2 я прекрасно понимаю зачем нужен EAV конкретно вам, и зачем он нужен в принципе. Более того, я год назад уже отвечал на такой же вопрос: Как спроектировать базу данных? . И вот еще на один подобный Как добавить товар в корзину? . Я вам говорю, что если вы еще в начале проекта, то возможно стоит принять решение использовать для характеристик о товарах документную базу. Если это невозможно, то вы нагуглите массу информации по EAV.
k-2 в том, что вы используете реляционную модель не по назначению. EAV "разворачивает" вашу схему перпендикулярно, и вместо того, чтобы было по одному столбцу на каждое свойство товара (что невозможно в вашем случае по причине изменчивости свойств), у вас будет по одной ЗАПИСИ на каждое свойство каждого товара. Т.е. по сути это борьба с реляционной моделью, попытка получить от неё полу-структурированные, для чего не предназначена.
Это решение приемлемо для небольших объемов данных, или если поддерживать другую СУБД значительно сложнее, чем поддерживать EAV в реляционной.
Daniel Newman
Так а что конкретно вам мешает сделать эту таблицу логов одну на всех? Ну залейте ОДНУ её копию в отдельную базу (чтобы продакшен не трогать) и поставьте права только на чтение (SELECT), и пусть девелоперы ковыряются. Если read-only не годится - ну тогда сделайте тестовые выборки небольшие, процентов 5-10 допустим, и используйте их. Я поэтому и спрашивал про структуру этих логов, т.к. непонятно, для чего они, и какой процент от этих логов можно использовать в качестве полноценных тестовых данных. Т.к. если это логи событий - то событий можно взять последние 100/1000 штук, а не все миллион, а если это какие-то логи синхронизации, то тут уже надо внимательнее.
landergate кстати спрашивает у вас то же самое - что это за дампы, зачем они нужны, зачем дампить базу с логами, почему надо дампить всю базу, а не только схему? Такое ощущение, что нужно просто завести на проекте нормальные тестовые данные и тестовую базу скромного (но достаточного) размера. Что ж это за проект, где всем девелоперам нужны шестигиговые логи? Расчёт процесса слияния черных дыр? ;)
