К сожалению, по «легкому пути» вы уже опоздали на автобус.Поскольку самым простым способом было бы сделать это уже задуманным.Было бы не так уж и тяжело включить OwnerId в данные, уже находящиеся на первом этапе, и заставить вашу бизнес-логику работать в соответствии с этим.
В настоящее время «простой способ» заключается в рефакторинге всех ваших данных и бизнес-логики с включением OwnerId.И при этом смотрите в будущее.Подумайте о ситуациях «что, если нам нужно поддержать то и это в будущем», и оставьте немного места для будущего с помощью дизайна.Вам не нужно полностью реализовывать все прямо сейчас, но вы поймете, как легко масштабировать ваше приложение, если оно было разработано для масштабирования.
То, что приходит к ApplicationId, этоВнутренний идентификатор для вашего членства обеспечивает охват ваших данных о членстве по заявке.Я бы держался подальше от этой логики до всей вашей заявки.Имейте в виду, что аутентификация ваших веб-пользователей, назначение им ролей и предоставление им прав через роли - это совершенно другой процесс, нежели владение данными.
В ASP.NET MVC вы должны использовать атрибут [Authorize], чтобы убедиться, что определенные действия могут или не могут быть выполнены определенными пользователями или группами при определении того, какие данные, чьи, должны быть реализованы в самих данных.Даже если вы запустите два или более экземпляров своего приложения, оно все равно будет одним и тем же приложением.Так что ApplicationId здесь не работает для определения объема ваших данных.
Но, допустим, ваш CRM не будет таким уж маленьким в будущем, и станет очевидно, что ваша первоначальная организация или одна из последующихЧтобы разрешить своим клиентам входить в систему и проверять их данные, вам необходимо создать другое приложение для входа в систему клиентов.Этот сайт будет использовать другой applicationId, чем ваш CRM.Тогда ваша клиентская организация может сопоставить учетные записи пользователей с их записями CRM, чтобы их клиенты могли их просмотреть.
Итак, поскольку ваша CRM (все еще) мала, самый простой способ - разработать хорошую схему для вашей clients для сохранения, а затем пометьте все свои данные CRM OwnerId.И это OwnerId не может быть получено из таблицы пользователей, таблицы членства или где-либо еще.Он должен прийти из таблицы, в которой перечислены законные владельцы данных.Если вы хотите назвать их Организации, Компании, Клиенты или что-то еще.Это не может быть userId, roleId, applicationId и т. Д., Поскольку пользователи могут выходить из организации-владельца, роли распределяются между организациями (по крайней мере, теми, которые используются для определения доступа к определенным действиям MVC) и applicationIds предназначены для определения членства и ролей между различными типами клиентских приложений.
Так что вам здесь не хватает таблиц, описывающих владельцев записей CRM и отображающих все данные их владельцам.И для этого нет простого пути.Вы уже продолжали развивать CRM, думая, что «это просто простая организация CRM, так что давайте сделаем все проще».Теперь у вас есть «простая многоорганизационная CRM и вы просите простой способ избавиться от первоначального недостатка дизайна. Следующим шагом будет вопрос о том, как заставить ваш« не такой простой многоорганизационный CRM »легко делать то, что вы не делали.Во-первых, не принимайте во внимание.
Простое решение состоит в том, чтобы разработать масштабируемое приложение и сделать «немного» дополнительного для поддержки будущего роста. В долгосрочной перспективе это будет намного проще, чемтратить много времени на переписывание приложения два раза в год. Также имейте в виду. В конце концов, это CRM, и вы не можете сказать, кто использует его в своем бизнесе, у кого выходной, так как мыисправление некоторых вещей в CRM.
Я здесь не покровительствую вам. Я отвечаю всем, кто может читать это, чтобы прекратить поиск простых решений для восстановления после неадекватного планирования. Их нет.И поиск одного делает одну и ту же ошибку дважды.
Вместо этого возьмите ручку и бумагу, спланируйте работоспособный дизайн и заставьте его работать. Приложите дополнительные усилия на ранних этапах проектирования и разработки программного обеспечения, и вы обнаружите, что эта работа сэкономит вам бесчисленные часы в процессе. Таким образом, тот, кто использует вашу CRM, останется доволен ее использованием. Становится легче говорить с вашими пользователями о будущих изменениях, в то время как вам не нужно думать «я не хочу этого делать, потому что это снова сломает приложение». Вместо этого вы можете вместе насладиться мозговым штурмом следующего крутого шага. Некоторые из идей будут оставлены на потом, но некоторые возможности для реализации будут разработаны уже на этом этапе, так что фактический год реализации будет проходить гладко и будет приятным для всех вовлеченных сторон.
Это мое простое решение. У меня есть 15 лет развития и тот факт, что я все еще наслаждаюсь этим, чтобы поддержать вышеизложенное. И это главным образом потому, что я принимаю каждую (ну, в любом случае, большинство из них) как возможность лучше разработать код, а не пытаться уклониться от неизбежного процесса. У нас есть старая поговорка в Финляндии: «Или ты это сделаешь, или ты будешь плакать». И это идеально подходит здесь. Это зависит от вас, если вам так нравится плакать и идти «легким путем» сейчас.