А как сейчас с работой?
Я до конца в этом не разбираюсь
Это твой шанс. Если не сейчас начать разбираться, то когда?
Вопрос - зачем всё это делать, если можно просто иметь либы с нужными типами где-то в репозитории и линковать их оттуда?
Из описанной тобой каши сложно сделать какие-то выводы, могу лишь сказать, что ты не там виноватого нашёл.
Сейчас точнее напишу, а то я тут чего-то может наврал.
Вобщем, конкретный код, что у меня вылетает:
Type type = Type.GetTypeFromCLSID - тут передаётся GUID из настроек приложения и имя сервера (у меня это локалхост) - тут же и вылетает, т.к. данный гуид не зарегистрирован (потому что сервис, где он зарегистрирован, не запущен, или как-то так).
Далее, если получаю таки этот тип, то он создаётся удалённо:
Activator.CreateInstance(type)
но до этого не доходит - вылетает на предыдущей строчке.
Как я понял, эти типы крутятся где-то в другом процессе и моё приложение создаёт объекты в этом процессе удалённо и использует их (тоже удалённо?). Зачем и почем так сделали - не знаю. Клиентское приложение - обычный веб-проект (сделанный, правда, на технологиях 20-летней давности). Чем было хуже просто сделать либу с типами, пошарить её между сервером и клиентом и гонять объекты через какой-нибудь REST?
Время идёт, System.EnterpriseServices, в котором этот interop крутится, устарел и больше не поддерживается в новом .NET, а REST как был, так и остался.
Что за идиотизм, общаться одними интерфейсами?Можно попробовать без них.
Вот простая задача - отослать email, как бум делать? Каким способом будет отослан email неизвестно (сегодня одним, завтра другим), какие "секреты" (API Key, password) будут нужны тоже неизвестно.
Видимо switch хочется сделать? Или как?
Я имел ввиду, как выше написал, когда код выглядит примерно так
IInterface obj = GetObj();
где GetObj возвращает тоже IInterface. А реализаций этого интерфейса куча. И как мне УДОБНО попасть в нужную реализацию без перебора всех реализаций и запуска приложения? При ошибке можно по стеку ориентироваться - но это искать в проекте файл, потом в нём функцию. При Go To Implementation - копаться в имплементациях. А я хочу просто дрюкнуть Ф12.
Что за идиотизм, общаться одними интерфейсами?
Идиотизм - общаться не интерфейсами :)
Только под дебагом и можно попасть в нужное место. А дебажить не всегда удобно или можно.
В CallStack'е всегда видно в какой именно имплементации произошла ошибка. Если CallStack'а нет, то логгер пишет имя класса :)
Если у вас сделать как-то иначе, то вы сами себе злобные Буратины.
так Алекс же себя всем этим буратинам противопоставляет.
типа это все они.
А я хочу по Ф12 попасть сразу в нужное место! Мне так удобнее!
Один фактик - проект юзает либу NHibernate версии 1.2.0, которая ещё без nullable types - времён очаковских и покоренья Крыма (где-то 2005-2006 года). Для nullable types юзается какое-то то ли самописное расширение, то ли более поздняя "заплатка". Как такое заюзать в .NET 5 без переписывания всей подсистемы запросов в БД?
так Алекс же себя всем этим буратинам противопоставляет.
Да я себя иногда ваще Карабасом чувствую!
А я хочу просто дрюкнуть Ф12
Опять что то мы о разном. Может что-то одно вначале обсудим?
Вроде занялись интерфейсами, а не как удобно попасть в нужную реализацию.
А я хочу по Ф12 попасть сразу в нужное место! Мне так удобнее!
Если все имплементации в одном солюшене, то студия предложит выбор.
Один фактик - проект юзает либу NHibernate версии 1.2.0, которая ещё без nullable types - времён очаковских и покоренья Крыма (где-то 2005-2006 года). Для nullable types юзается какое-то то ли самописное расширение, то ли более поздняя "заплатка". Как такое заюзать в .NET 5 без переписывания всей подсистемы запросов в БД?
ЕМНИП nullable type - это синтаксический сахар. Nullable<T> спасет отца российской демократии :)
Опять что то мы о разном. Может что-то одно вначале обсудим?
Вроде занялись интерфейсами, а не как удобно попасть в нужную реализацию.
Да мне сразу почти всё в проекте не нравится. Мне надо решить проблему, а как будто всё против меня там сделано. Зато архитектура...
Посмотрел, как запросы к БД делаются. Лять, это что-то. Сам SQL хранится в XML-файлах с параметрами в виде тегов. Код берёт XML, парсит, вставляет параметры. Затем ещё какие-то свои классы заведены для "универсальных запросов" - класс Query, где есть свойство QueryType, которое enum (SQL, HML - последнее это аналог LINQ, только 15 лет назад, в NHibernate и куда проще и хуже). И в этом классе есть свойства типа Where и OrderBy - это типа объекты, представляющие собой части запросов. И вот они там забавляются с этим своим Query - то как SQL его задействуют, то как HML. Query, Where и OrderBy каждый примерно по несколько тысяч строк "весит". Я такого изъёбства нигде больше не видел. Типа ORM должна облегчить взаимодействие с БД, но эти наворотили так, что как будто в несколько раз усложнили. Зато у них типа запрос сериализуется. Плять, а строку никак передать? Естественно, каждый запрос - стек из пары десятков вызовов только своих функций (а есть ещё библиотечные) - пока там распарсит, пока вытащит запрос с параметрами, пока соберёт его, потом сериализует - на другом конце всё в обратном порядке. Лучше бы чистыми строками сделали. Похоже, что NHibernate в первых своих версиях только всё хуже и сложнее делала, чем строковые "голые" запросы.
Я бы сказал, что shared library - это DLL, которую установили в GAC :)
------
Скорее - наоборот - те, что не втыкаются в ГАК...
ЕМНИП nullable type - это синтаксический сахар. Nullable<T> спасет отца российской демократии :)
В той кастомной реализации, что у меня - это свои классы с перегрузкой кучи операторов и прочим. Придётся конвертить в дотнетовский Nullable<T>.
Понятно, что всё можно сконвертить и переделать, но когда читаешь этот код - натурально...
я хочу по Ф12 попасть сразу в нужное место
------
Напиши небольшое расширение - там не сложно... Но! учить опять таки придется...
Я бы сказал, что shared library - это DLL, которую установили в GAC :)
------
Скорее - наоборот - те, что не втыкаются в ГАК...
Ну вот, мнения как всегда раСтроились. Я бы вас двоих запер в тесной комнате с мягкими стенами, убрав оттуда все колеще-режущие предметы. При этом обоих бы назначил тимлидами. Над одним проектом. И ждал бы, пока вы не придёте к общему знаменателю, что же такое shared library. А сам бы подглядывал в окошко - как там дела идут.
))
Мне надо решить проблему
Ну так там тоже решали какие то проблемы, только другие.
Сделано похоже не очень хорошо. Хотя там же должны быть интерфейсы к запросам. Сколько таблиц в базе?
Да мне сразу почти всё в проекте не нравится.
Вполне можно понять, кому нравится в г-е копаться.
Вопрос в том, будем ли дальше с интерфейсами разбираться или ну нафиг? Главное поворчали.
Сколько таблиц в базе?
------
А ты не хочешь спросить какие из баз поддерживаются? Без перекомпиляции, естественно.
Сделано похоже не очень хорошо. Хотя там же должны быть интерфейсы к запросам.
Не так немного. Интерфейсами там всё вокруг обделано - провайдеры, менеджеры, коннекторы, фабрики. Они вокруг этих запросов танцуют. Типа возвращает не тип таблицы, а провайдер таблицы. Ну и на провайдер конечно интерфейс. Поэтому, чтобы получить что-то из таблицы, я сначала получаю провайдер в виде интерфейсного типа, у него запрашиваю что-то из таблицы, мне возвращают ещё один интерфейс.
Ну и конечно на большинство этих интерфейсов по одной реализации. А нахрена тогда городить интерфейсы? Зато кода в 2 раза больше - проект с чисто интерфейсами и проект с чисто реализациями. Похоже, делали в той эпохе, когда все эти паттерны ради паттернов самую лютую популярность набирали. А то - вдруг нам в будущем, лет через 15, придёт в голову вторую реализацию интерфейса придумать? А оказалось, что через 15 лет это оно переписывать задолбаешься даже с одной реализацией. Выкинуть нафиг все интерфейсы - солюшен на штук 4-5 проектов похудеет.
Сделано похоже не очень хорошо. Хотя там же должны быть интерфейсы к запросам. Сколько таблиц в базе?
Да я уже там потихоньку разбираюсь. Начальники заказчика говорят, что там чуть ли не половину проекта будут выкидывать - всё это понаписанное нафиг не нужно. Мне сказали, чтобы я максимально простую новую реализацию GUI сделал, по возможности обернув старую логику. А получается, похоже, что придётся и логику переписать на значительно более простую - чтобы сразу через ORM к БД стучаться, а не через сервис в отдельном процессе, интероперабилити и создание и использование типов удалённо в других процессах.
Блин, там даже веб-морда сделана в лучших традициях старого шаманизма - куски интерфейса на HTML-фреймах. Боковое меню - фрейм. Подвал и заголовок - фреймы. Ну и центральный блок с данными - фрейм. Веб-контролы с данными (типа списков и таблиц) выполняют у себя всякие фильтрации на языке HQL.
Сколько таблиц в базе?
Под сотню. Плюс ещё несколько десятков какого-то мусора с названиями от "Test1" до нечитаемого набора букв и цифр. БД вроде MS SQL Server, но это тестовая вроде. К проекту ещё и оракловские либы зачем-то подключены.