Опт. решение для разделения объектов данных от чтения/записи и отображения
Фактически IEditor повторяет структуру объекта и это не редактор, а IDataObjectXDefinition
public interface IEditor
{
string Name { get; }
int Length { get; }
IEnumerable<IEditor> SubItems { get; }
bool IsAvailable { get; set; }
}
Сейчас именно так и сделано. Из "читалки" выходят интерфейсы данных, имплементация внутри. Думал может, что лучше можно найти.
Объекты то ведь не такие простые, их еще нужно удалять и модифицировать и внутри еще списки, то бишь нужна ObservableCollection и WindowsBase assembly. Что не очень то хочется для Консольных и Винформс проектов.
До "писалки" пока еще не дошел, будут наверняка новые проблемы.
Или ты в лучших традициях Murr'а утаил какие-то детали?
Вполне возможно 
Не так и просто все коротко описать. Я вот когда первый вариант писал, нашел одно решение, но после оказалось мало.
Ну и понятно что 100% решения не будет, но иногда высказывания могут дать новый импульс для размышлений.
но приведите простой КОНКРЕТНЫЙ пример
Хм, простой... Не знаю пока.
Но вообще с делением на "конкретников" и "абстрактников" познакомился давно. Как то объяснял коллеге что то и потом смотрю, что не понимает он решение. В итоге выяснилось что мы на разных полюсах. Без конкретного примера ему ничего нельзя было рассказывать.
Но зато как это понял сразу пошло нормально. Так что сорри, привык максимально абстрактно описывать.
Если немного конкретно.. и попроще.. 
Есть объект "параметр", читает имя поля и тип объекта, если тип объекта numeric, то читается еще значение по умолчанию. Затем читается конкретный тип.
Из типов: bool, int, double, string, различные комбинации Dictionary (int-string, string-double, int-double) включая еще и различные вложенные словари x-Dictionary<k,y>
И это всё нужно показать в одной таблице и также иметь возможность редактирования всех типов данных. При этом нужно еще пользовать С++ либу для чтения.
Кроме этого есть еще и другие подобные объекты.
и снова вы "паки-паки", "иже херувимы". языками не владеете?
вы ведь уже и "кодировать начали". не решили только пока, что именно. я действительно, не поняв, чего хотят, не въезжаю. ладно, примем, что это я туплю, не берите в голову. приятных вам абстракций : )
паки-паки...
уже и "кодировать начали"
Нет времени на раздумья и поиск лучшего решения. Это всё как бы на будущее ну и ли в процессе что то изменить в лучшую сторону.
Заказчика интересует конкретный продукт в минимальные сроки.. Всё остальное интересует только меня.
я действительно, не поняв, чего хотят, не въезжаю
Ну значит что то не так описал Просто не знаю как описать лучше. Я и сам то пару недель врубался что нужно, а как это за пару минут описать...
относится к заглавию и первому посту
что такое:
0. объект данных
1. отдельный проект
2. внутренний проект
3. наружа
4. запись/чтение (и куда/откуда)
5. в " изменения удобно делать" какие изменения
6. что "все вместе" и с какой стороны что
7. разделение от чтения/записи и отображения
Заказчика интересует конкретный продукт в минимальные сроки..
ну, это было вашей задачей (и сейчас еще остается), разъяснить клиенту, в какие реальные сроки какого качества и цены сопровождения продукт он может реально поличить. чтобы родился жизнеспособный полноценный ребенок, необходимо 9 месяцев. до семи, говорят, тоже потом догонит. но кто хочет за 5-6 родить, получит слабого и отсталого, если вообще живого. и это не зависит никак от того, что интересует или не интересует заказчика.
Фактически IEditor повторяет структуру объекта и это не редактор, а IDataObjectXDefinition
Тут не совсем понятно, что тогда такое IEditor. Я думал, что это ViewModel для редактора.
Если уж ты говоришь о ObservableCollection, значит речь о WPF и, следовательно, в MVVM.
Итак, модель у тебя каким-то образом создает (считывает из файла, получает из БД, генерирует случайным образом) объекты с данными. Кроме этого, у нас есть View - редактор и и есть ViewModel - этот объект должен знать структуру объекта с данными и должен знать, что будет отображать редактор.
Т.е. никаких сюрпризов тут нет и быть не может. View точно знает какие данные он может отобразить (т.е. работает с заранее известным интерфейсом ViewModel). ViewModel в свою очередь точно знает модель и интерфейсы всех отображаемых данных.
Так в чем проблема-то? :)
Тут не совсем понятно, что тогда такое IEditor. Я думал, что это
а мне также совсем непонятно, как вам хоть что-то понятно. вы привыкли выполнять задачи на основании догадочной документации? мне когда-то (один раз за все время) пришлось начинать с "техзадания", похожего на первый пост Алекса. месяца два мурыжил его, пока не получился некий документ (документом он в строгом смысле не был), позволяющий сделать вывод о том, что должно быть разработано, что оно должно делать (а чего - нет) и как. а до того только слышал от шефа "сроки поджимают! когда ты наконец приступишь к кодированию!". неприятное время было, но иначе просто не могу. сорри.
а мне также совсем непонятно, как вам хоть что-то понятно. вы привыкли выполнять задачи на основании догадочной документации?
оно почти всегда так. есть какие-то обрывки информации и приходится поятоянно что-то уточнять, переделывать итд.
В худшем случае у меня происходит так: шеф 2-3-4 месяца переписывается с клиентом, потом приходит с километровой простыней е-мылов и спрашивает "сколько на это надо времени", потом опять пауза на пару месяцев, потом приходит за неделю до дедлайна и говорит, что надо оставить все задачи и пилить новую фичу. Постит при этом ту самую километровую простыню е-мылов типа там есть вся информация :D
значит, нужно самому взяться и написать какое-нибудь примитивное техзадание и дать всем на подпись или просто на ознакомление. на это уйдет время, но сэкономится больше. ясно, писать доки никто не любит, но без этого просто нельзя. ну, если задача - не хэллоуорлд какой-нибудь : )
Проблема в том, что когда я получаю задание, то дедлайн уже "вчера".
Ну и подписывать мне не с кем, я с клиентами на прямую не общаюсь. Так что обсуждать могу только с шефом. А давать что-то на подпись шефу - это уже перебор :) Если мне что-то не понятно, то задаю вопрос в емыле и все.
жаль, что алекс исчез, и мне его так и не удалось раскачать на вразумительное условие задачи. ведь иногда стоит задачу переформулировать, и рашение уже читается из условия.
гешефтсидея: вынудить ИИ из потока имэйлов шефа выстроить несколькостраничное техзадание. вот только как их удобнее разделить от чтения/записи и отображения ; )
имею отрицательный опыт в этом плане. руководитель проекта как-то получил свежее техзадание на очередной проект (крупная фича), и говорит, что я, мол, доку на сервер выложил, но чтоб тебе не читать и не морочить голову, я тебе сейчас за 5 минут все обрисую. и обрисовал. выглядело вполне плаузибельно. я и сваял на первый тест нечто, что он описал. оказалось, что одну "мелкую деталь" он то ли опустил, то ли неправильно изложил, как я узнал, прочтя таки все техзадание от корки до корки, но пришлось переделывать, ставить заплатки и пр. с тех пор ВСЕГДА хочу начать с того, что ознакомлюсь с документом. в дальнейшем этот же руководитель проекта вел себя точно также, я его вежливо дослушивал до конца, благодарил, но, выйдя от него, шел читать техзадание. и НИ РАЗУ не пожалел. если бы было нечего читать, я бы начал с того, что сам бы хотя бы пару страниц написал. хотя бы в виде перечня каких-то утверждений. что должно быть, и чего не должно. и держал бы актуальным. а документация в виде шефа - это ненадежно. дай ему бог здоровья, но сегодня это особенно актуально.