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