Ninja Mate: то о чем говорите, больше похоже на Union(обЪединение отдельных запросов). Не путаете Join и Union. Join всего лишь соединяет таблицы в рамках одного запроса.
eRKa: Хорошо, я не буду вдаваться в тему релизует ли EF репозиторий или нет. Вообще очень похоже, потому что получаемый DbContext являеся аналогией UoW, а каждый DbSet, через который я могу и осуществлять CRUD, является аналогией репозитория.
Вопрос-то вот в чем. Я получил POST-запросом в контроллере объект ViewModel. Затем здесь же я инстанцирую доменный объект и инициализирую его значения из ViewModel. Далее вызываю dbContext.Orders.Add(model), где model -инициализированный ранее мною объект. Это ОК подход?
У меня существует экшн Create в контроллере. Я могу принять POST-запроса различными способами начиная от request.form заканчивая моделями. Насколько я понимаю рекомендуется оперировать моделями. К тому же она у меня уже связана с View. Вот я получил на вход ViewModel. Как мне наиболее оптимально имплементировать CRUD - операции?
Применяю Entity Framework, который уже имплементирует Repository Pattern, так? С учетом того, у меня слой данных простой(используется один источник БД), я делаю вывод, что никакие репозитории уже к контексту, сформированному EF-ом, я не имплементирую. Каждый, имеющийся в распоряжении у меня DbSet уже является своего рода репозиторием, верно?
Соответсвенно мне на вход Context.Add() нужно передать доменную модель. В контроллере я получил ViewModel. Будет ли инстанцирование объекта доменной модели с последующей инициализаей свойсв из полученной ViewModel оптимальным вариантом?
Моя неточность, в описании вопроса.
Сущность Car уже определена, отношения между Order и Car были инициализированы на этапе проектирования БД.
Соответсвенно, Entity Framework мне сгенерировал в модели Order
виртуальное свойство public virtual Car Car { get; set; }
Я этим вопросом, думаю, больше запутал.
Смысл в том, что при создании OrderItemViewModel я делаю ссылку на Data.Order
А при создании OrderCreateViewModel я написал дополнительную модель для, чтобы хранить там List для автомобилей.
Вопрос в том, что будет ли оптимальным расширить доменную модель partial class Order поместив туда дополнительное поле List для автомобилей?
можно задачу назначить не пользователям отдельным, а группам.
.Группы предварительно создать через администрирование, в настройках проекта добавить эту группу как участника и потом уже ей назначить задачу.
Дѣаволъ: не думаю, что фраза "понятно, что программистов 1С оптимизация не особо интересует. Главное чтобы работало. Оно и понятно: support - это хлеб" - верна. Так можно сказать о любой клиентской разработке ПО. Единственное, что точно могу утверждать: 1С в свое время создавалась для быстрой реализации систем для бизнеса. Чтобы ты основное время тратил не на разработку формочек и проверок ввода данных в них, а настраивал реальные бизнес-процессы. И это сработало да, правда в угоду производительности - местами 1С косячная, но она по сути единственная альтернатива для компаний: можно написать на коленке за два дня простую конфигурацию для склада на 5 сотрудников. И потом в случае чего найти саппорт, если что-то потребуется.
Сергей Плаксиенко: что значит дополнительный признак внутри трекера?
Постараюсь изложить мою проблему уже с новым видением на систему Редмайн:
Пользователям предлагается оставлять заявки на техничесукую поддержку. Предположим, есть три вида заявок: права доступа, запрос на разработку, другое. Каждый из перечисленных видов заявок имеет свои обязательные атрибуты. Редмайн поддерживает настройку различных атрибутов для трекеров: окей, пусть это будет трекер у нас.
Также мы имеем ввиду, что для двух видов заявок у нас две группы исполнителей: права доступа, запрос на разработку. Для вида "Другое", к примеру, задача приходит всем сразу и может быть переназначена кому-то конкретно из всей группы поддержки. Настроить автоматическое назначение мы можем по группам в проекте. Теперь вопрос: как связать между собой сущности "Трекер", по которой у нас разбиваются заявки на виды и "Категории", по которой у нас идет назначение задач?
Спасибо, Сергей, вопрос уже подобным образом и решен более месяца назад!
Единственное, что меня зацепило: почему назначать можно только по категории, а не, например, по трекеру?
К примеру, у меня есть проект, в этом проекте существует несколько трекеров, по направлениям которых и разбиваются задачи. Мне было бы удобно назначать уже по трекеру исполнителей, т.к. дополнительная детализация по категории не требуется. Сейчас я просто создал такие же по названию категории, как и трекеры в проекте. Теперь каждый раз при создании задачи приходится в поле "Категория" выбирать тот же пункт, что и в трекере. Костыли((
@opium: нашел в свойствах проекта категорию задач. Вот по этой категории назначение идет автоматически, НО! одной категории в соответствие можно добавить только одного исполнителя, мне же нужно несколько.
@opium: вот, выставил эту группу поддержки. При создании новой задачи нужно выбрать исполнителя и возможные варианты как раз берутся из этой группы поддержки. Но мне не нужно, чтобы пользователь выбирал кому задача падает, нужно чтобы задача приходила всем сразу.
Поправлю формулировку: мне нужно, чтобы запрос данного вида уходил к исполнителям с данными скиллами. Без необходимости выбора исполнителя, пользователем. В теории пользователю, который создает реквест, вообще неизвестно кто чем занимается в поддержке. И ему это не нужно знать.