我发现了很多关于在不同地方保存不同类型的应用程序/用户设置的信息,但是对于我来说这可能是最好的方式。
我的问题有不同的维度:
(4.应用程序是用C#编写的)
我不想提及我读过的东西,因为我不想把你的想法引导到(可能是错误的)方向。 那么,你将如何处理这种情况?
非常感谢!! 约尔格
编辑1
在我希望的第一个答案之后可以澄清我的问题的其他一些事情:
ConfigurationManager
- 班级
...我对这个没有经验但是据我所知这个类只是另一个类让我可以访问我的ApplicationSettings(和#1一样有问题)答案 0 :(得分:0)
我想在这种情况下你可能有一个数据库。当您在其中合并用户,用户权限等时,它可能也是保存应用程序设置的好地方。
我一直很喜欢以数据库为中心的解决方案,因为有广泛的可用性(当您想要基于同一系统创建新的UI时,您可以重复使用那里的设置)。
我认为实体 - 属性 - 价值模型是一个很好的设计策略。
您可以创建一个带有触发器的视图,隐藏仅系统属性,使管理员可以更改所有属性,用户只能更改他们的属性。
答案 1 :(得分:0)
根据您的描述,我想说你想要Role Based Authentication。这是asked before的事情。我将转到link specified in that answer查找如何解决此问题的概述和一些代码示例。
Microsoft在成员提供商和现在的ASP.NET身份框架(如果您有Web应用程序)中添加了一些抽象方面做得非常出色。无论您选择做什么,都会涉及数据库或配置文件(看看here以了解如何管理这些文件)和某种claim derived system。
答案 2 :(得分:0)
假设:您已经了解了如何处理角色,而您的问题仅仅是存储/检索设置。
第3点意味着您不能将Settings文件用于应用程序和用户范围设置以及custom configuration section来保存角色特定设置(可选encrypted)。
我的下一个建议是一个WCF端点,它可以完整地公开设置(Application + User specific + Role specific的安全修整内容),也可以通过某种字典查找等效。此外:
<强>更新强>: 请注意,WCF不能解决您的存储问题,但它有助于您的第3点 - 需要使用相同设置的多个项目。 WCF端点允许封装多个客户端重用的设置存储/检索的单个项目。 WCF可能很复杂,但实际上它很容易设置 - 你只需装饰一个接口并在IIS中托管它。如果你不喜欢使用IIS,你也可以自己托管Windows服务,但是将它部署到IIS会容易得多。然后,您可以通过向项目添加服务引用来在其他应用程序中使用它,然后调用接口代码,就像代码在您自己的项目中一样。
如果您正在讨论具有多个类库的单个应用程序:
我上面所描述的假设您正在创建所有需要共享设置的多个应用程序。如果您实际上是在讨论具有多个类库项目的单个应用程序,则仍然可以使用内置的设置 - 您只需要执行一个手动步骤即可使其跨项目工作。将设置添加到应用程序项目和类库项目后,应复制包含类库中设置的app.config部分,并将其复制/粘贴到应用程序的app.config中。 Visual Studio不是很聪明,它只会将类库设置更改同步到类库项目中的app.config,即使类库的app.config不是“真实的东西”,因为只有默认情况下,实际使用了使用类库的应用程序的app.config(这就是为什么需要将它合并到应用程序的app.config中)。
如果您需要多个类库(包括主应用程序项目)来使用相同的设置,您可以创建一个专用的类库项目来保存设置(请注意,您可以将多个设置文件添加到此项目以进行设置更模块化),然后所有其他项目都可以引用公共设置项目(为了避免循环依赖,你不会在主应用程序项目中保存类库所需的任何设置。)
覆盖用户的设置
Settings对象具有一种可用于覆盖设置的机制(例如,使用管理员指定的值)。将Settings对象添加到项目时,它会创建一个Settings部分类,其中包含一些示例代码,用于连接SettingsLoaded事件。在这种情况下,您可以加载管理设置(通过WCF调用,或者可能从文件系统上的已知位置)并应用任何替代。