Теперь, когда я закончил создание своего пользовательского интерфейса
До прочтения этого я думал, что вы закончили создавать свой бэкэнд
Я знаю, что это Не рекомендуется включать строку подключения, имена пользователей и пароли БД в файл App.config из-за риска возникновения проблем с поддержкой в будущем.
Если вы не собираетесь хранить строку подключения в Затем в app.config вам потребуется другой способ аутентификации, например windows учетные данные. Или вам нужно зашифровать разделы конфигурации вашего приложения. Это больше о безопасности, чем о будущем обслуживании. Если что-то не помещает подробности соединения db в ваш app.config, это создаст больше проблем с обслуживанием, потому что по большей части все спроектировано так, чтобы ожидать, что именно там они и будут. Вы можете хранить их в текстовом файле или каждый раз запрашивать их у пользователя, если хотите, конечно
Я считаю, что лучше всего было бы иметь своего рода слой между моими приложение и моя база данных, где я могу хранить информацию о соединении, чтобы мое приложение могло взаимодействовать с этим слоем и слоем с БД.
Дело не столько в хранении деталей соединения; это звучит так, как будто вы начинаете врываться в типичную архитектуру наличия слоя данных, который имеет дело с объектами в базе данных, и уровня бизнес-логики c, который имеет дело с операциями, которые бизнес должен выполнять с использованием одного или нескольких объектов уровня данных. , Создание новой учетной записи потребует информации о человеке и адресе, и уровень данных может отражать их как разные вещи, тогда как бизнес-уровень думает о них как об одной вещи, жизненно важной для определенного процесса
how я делаю это?
Большинство людей делают это, откладывая связанные с данными вещи в библиотеку, такую как EF, которая интересуется БД и сущностями, которые она содержит, и моделируя их в коде. Тогда у вас есть набор классов определить операции, которые вы будете выполнять для достижения бизнес-цели, и набор классов хранения данных, которые поддерживают эти операции, и набор процессов для отображения бизнес-объектов на объекты сущности базы данных; CreateAccountModel генерируется пользовательским интерфейсом и передается методу CreateAccount AccountRepository; внутренне репозиторий учетных записей знает об объектах Person и объектах Address в БД через контекст db и будет создавать каждый из них, используя данные, найденные в CreateAccountModel. Это отключает бизнес-процесс создания учетной записи от того, что хранит данные. Концептуально вы можете поменять базу данных на другую, в которой хранятся данные о личности и местоположении, а не о человеке и адресе, и бизнес-уровню это безразлично. Читайте вокруг по теме; нет правильного или неправильного способа сделать это, так что это не простой вопрос представить основанный на фактах ответ на
Я видел ответы здесь, которые предлагают создать службу WCF
WCF - это фреймворк для веб-сервисов; веб-сайты, которые компьютер может использовать вместо человека. Вы можете добавить этот уровень абстракции наверняка, но на самом деле вы захотите сделать это только в том случае, если ваш пользовательский интерфейс каким-то образом очень далек от вашего центра хранения и обработки данных, или ваша финансовая модель бизнеса основана на предоставлении вашего программного обеспечения в качестве услуги для кто то. Я не ожидал бы, что пользовательский интерфейс, который используется локально и имеет свою собственную БД, будет нуждаться в сложности работы по сети, если все, что он когда-либо сделает, - это вызов службы на локальной машине
должен ли я просто сдаться
Это не вопрос, на который ТАК предназначен для ответа. Вопрос не в том, что опытный профессионал спрашивает
Нет ли документации с открытым исходным кодом, имеющей такой тип реализации?
Существуют миллионы проектов и тысячи архитектур; это должно сказать вам, что есть несколько способов сделать что-то, и, в конечном счете, правильно, это субъективно / мнение. Если это работает и не оправдывает ожидания sh и отвечает ожиданиям клиента и не требует от вас больше затрат на постройку и обслуживание, чем вам заплатили, вы могли бы сказать, что это было правильно
Во-вторых, есть ли другие рекомендации, которые мне следует знать о моих приложениях?
Вероятно, сотни из них, но не вопрос, поэтому SO предназначен для ответа
Это нормально?
Соответствует ли оно критериям за то, что все в порядке?
Для подключения к приложению требуется имя пользователя и пароль. Эта информация хранится в одной таблице в моей БД. Я думаю о шифровании поля пароля.
Пароли всегда должны быть односторонне зашифрованы. Вы берете то, что вы дали пользователю, применяете одно и то же одностороннее шифрование и сравниваете результат с сохраненным шифрованием. Тот же результат, пароль, предоставленный пользователем, был хорош
Приложение может быть распределено по нескольким клиентам. Я имею в виду реализацию трех разных баз данных (Test, Accept и Production, возможно, также на разных серверах), и для каждого клиента я создам конкретную c схему в БД, чтобы у каждого клиента были свои объекты. Таким образом, никогда не происходит взаимодействие между данными от разных клиентов. Проблема в том, что предоставление приложения новому клиенту потребует настройки всего (схемы, таблиц, процедур, функций, ...), но я чувствую, что это может вызвать проблемы с обслуживанием, поскольку каждое изменение должно быть применено ко всей схеме каждого клиента.
Мы не можем ответить ни на один вопрос, так как не знаем, как ваш целевой рынок хочет разделить данные. Большинство компаний, которые подписываются на услугу, в порядке, когда они делятся БД с другими клиентами и достигают разделения, используя некоторые средства данных в таблице, такие как «клиенты имеют свой собственный совершенно случайный GUID, тогда у всех учетных записей есть клиентский номер, все у пользователей есть учетная запись et c .. ", поэтому существует определенная иерархия данных и разделения.
Если у вас будет всего несколько клиентов, и они требуют высокой степени отделения от коллег, вы можете рассмотрите возможность создания новой базы данных (той же структуры, разных данных) для каждой из них, потому что работа с несколькими разными схемами с одинаковыми таблицами может быть кошмаром
Восстановление соединения с БД, хотя можно включить строка подключения в App.Config, в Visual Studio, также есть возможность прямого подключения к базе данных в источниках данных.
Есть, но вы можете обнаружить, что ваша строка подключения в конечном итоге хранится в в любом случае файл конфигурации. Visual Studio обычно не присутствует на клиентском компьютере, на котором выполняется приложение, поэтому все, что она знает, что жизненно важно для работы приложения, связывается с приложением при публикации sh
Какой наилучший подход ?
Не вопрос, так что предназначен для ответа, извините