I want to re-code my existing project (WPF Code-Behind) in MVVM and want to make much better.
In the old project i saved all (including MySQL Connection Info) in App.config.
But I read that this is much unsecure and not recommended. So I want to ask you, whats the best and securest way for MVVM to save and read config.
In the Config I want to store following for example:
bool StayLoggedIn (When Checkbox at login is checked this should be true to stayloggedin, this can be unsecure)
string Mysql_DATABASE (the database)
string Mysql SERVER (the server)
string Mysql User (user)
string Mysql Password (password)
As you can see, people shouldnt see this config file. But the program should be able to read and write this file.
I can't use App.config too because I created 2 Projects in my Solution. 1 for my Views called Ui.Desktop and 1 for my ViewModels called Logic.Ui.
So Logic.Ui doesn't have App.config and I cant get access of the App.Config then. So there have to be another way.
You can still use the application configuration file with an encrypted connection string (or whatever other values you need). If the "Ui.Desktop" project is the solution startup project, that is the one that must have the app.config with the data in it. That is assuming of course that the "Logic.Ui" project is a reference.
I believe the better question to ask yourself is where are you placing your configuration elements? If you are building them in your "Logic.Ui" projection that would not be the correct project to do so. It is called "Separation of Concerns".
A better way of creating this solution might be to create a project that is concerned with starting your application, reading any configuration, and running whatever it is you want to run. If this is a WPF application place all of your views in a folder called "Views". If your "Logic.Ui" project has the ViewModel's then you can reference this project and use the classes you build in the "Logic.Ui" project. Let me know if this is unclear.
Related
I recently started to get into EntityFramework in order to map my model automatically into a MySql database. So I read some tutorials and started tests to validate them. Everything works fine, as far as I only have one project. If I separate the solution some problems arise. In order to demonstrate this, I set up a console project (lets call it A)with EF6.1 that saves all my data to the database. Everything works fine. If I now create a second console project (lets call it B) and and use the DbContext through a IRepository-Wrapper (from A) some problems occur:
First of all, I have to put my config data for the database and EF config into the App.config of project B. I don't like this, but I can live with this.
Furthermore the application compiles, but throws a exception, as long as I don't reference EntityFramework.SqlServer in project B.
In order to separate the concerns I don't want project B be to know that the data is stored via EF in a database. Or to give a real world example I don't want that my WPF Gui knows, that the data came from a database.
Is there a workaround for these problems? Did I miss something, or do I have to live with that problem when using EF?
For the first problem, you're not forced to put your connection string in the assembly's config file. You can use whatever you like (your own config/ini file, the registry, etc.), and then pass the connection string to the DbContext(connectionString) constructor.
As for the second issue, this seems to depend on how you are abstracting the database. If it is a complete abstraction, then it shouldn't leak any dependencies on EntityFramework.SqlServer. On the other hand, Entity Framework itself already follows the repository design pattern, so I'm not so sure if you need to add another layer on top of it. If you do want to continue with creating a database abstraction layer, consider putting it in a third library project that the other user-facing application projects reference.
I have a asp.net web project named FinanceTracker (which is under use for an year).
And the data is stored in Finance_Tracker_db.
(this is a intranet web site to track the financial data for an organization, accessed from
http://OrgTracker)
Now I have a requirement to have the same application for IT department.
everything is same on the data for both should be segregated.
So I created an empty copy of database name IT_Tracker_db.(on same database server)
And used the old code with modified connection string in web.config
(accessed from http://OrgTracker/IT/ deployed on same IIS server)
But as to have less maintenance to apply the same code to both deployed version, I am planning to use the same code with different connection strings.
Now I wish to have something like.
http://OrgTracker/ - This should show two links
http://OrgTracker/fincance/
http://OrgTracker/IT/
And based on user selected URL the proper connection string should be used from web.config
Like all pages will remain same like.
http://OrgTracker/fincance/Status.aspx, http://OrgTracker/fincance/Inbox.aspx, etc.
http://OrgTracker/IT/Status.aspx, http://OrgTracker/IT/Inbox.aspx, etc.
Can have more than one config
ASP.NET Configuration File Hierarchy and Inheritance
I suggest not doing this. First, it is complicated and out of build-in ASP.NET functionality.
Second, in some time in future your users can demand different things: one department would want newer version immediately, while the other one would want to have stable old version until they can test everything.
P.S. But if I were you, I'd start thinking about adding additional column called "Department" in all relevant tables so I could unite databases in future. This goes against my second point :), but it would make everything more manageable and architecturally sound, especially if more departments would want to use your application.
Im programming C# WinForm application which have big SQL Server Database.
I need to make setting.
I dont know how to save application setting. Which is better just add my solution .setting file or save in database Table?
I hate to say it, but it depends on whether the setting is intended to span all clients to the database, vs whether different nodes/applications would require different values. Having the values in the database can make it easier to centrally configure the system via the system itself (an admin page), without needing to re-deploy or reconfigure any nodes.
Disconnected clients can also work either way, as long as they capture the settings locally when connected (being able to connect at least once is not unreasonable).
Of course, even per-node settings can be in the db if you add suitable dimensions to the table. The one setting that is a pain, of course, being the connection details...
use application configuration file to save your app wise settings.
Depend of your needs, when use app.settings (tutorial http://msdn.microsoft.com/en-us/library/ms143432.aspx ) file it will be stored with application itself, when you strore them in database is more accessible.
You edit: (have) (sure you don't have, sorry for my poor english ....) you can to store configuration in the app.config file. Here's a post about using configurations files.
Informations will be accessible by the Configuration manager (Msdn link) Class.
We have lot of application parameters for each module in a C# .NET 4 ASP website.
parameter examples: timeouts, formulae constants, thread limits per module, $ charges per usage etc.
What is best out of following approaches we know:
Use DB config table
Use an xml. load that xml into local cache on start (and on xml change)
simple constants.cs file with public const int XYZ = 123; type of key-value pairs.
web.config (though i think its mostly for deployment type of config)
Any other way ?
Help on pros and cons and std. approach followed would be helpful.
I like #1, storing the values in the database, for several reasons:
This works on a web farm. You don't have to synchronize versions of web.config on multiple servers.
Making changes does not require recompiling and redeploying the application. Changes can be immediate.
It is relatively easy to create a maintenance web page for authorized users to update the values without bugging production support.
The values can be determined at any time from outside the application by anybody given access to the database (or to a maintenance page displaying the values). Nobody has to read through the source code or look at web.config files.
The web application does not have to be restarted for the change to take effect.
Edit: Additional comments about the other proposed methods:
If the app is going to be on a web farm, all three non-database choices will require deployment to all servers. This is not a trivial matter if a lot of web servers are involved, if the deployment procedure is complicated, or if corporate policy severely limits who (and when) changes can be deployed to production servers.
Even when there is no web farm, in a corporate production environment, it can be excruciatingly slow to deploy a change.
Regarding constants, I have found that they tend to get sprinkled all over the application code. Finding them can be a real challenge. Of course, if you have the discipline to centralize the configuration constants, you won't have this problem.
There is one other approach not on your list, which is using resource files (.resx). While this is generally used for localization, I have seen it used for configuration values, and especially for storing the text of standard messages. While you don't have to recompile your application to alter a .resx file, changing it will cause the application to restart.
In summary, then, my reasons for preferring the database approach are the speed and ease of deployment, avoiding recompilations and app restarts, centralizing the data outside the application, and making the data accessible to business users.
You seem to mix different level of setting together:
Timeout is best suited to be part of a web.config file, while
$ charges per usage is more related to a per-user setting and should be located in a database along with the user.
Should you decide to use a web.config file, I suggest the following to keep your web.config file clear of application settings.
Create a file that will store your settings. I usually create a file named as the application, like nerddinner.config. Remember that the config extension is used for security reason.
Add your setting in the file:
<appSettings>
<add key="Test" value="Hello world"/>
</appSettings>
In your web.config file, create the <appSetting>, but redirect it to the other file:
<configuration>
...
<appSettings configSource="nerddinner.config" />
...
</configuration>
In order of preference:
Web.config - The main benefit of using web.config is that the application pool is automatically recycled when the file changes. Also, you have the well-known System.Configuration API for accessing the data. You shouldn't have to muck around with a separate XML file and monitor it for changes when ASP.NET already has support for configuration files.
Constants file - This has the same app pool recycling benefits as the web.config, but it's more likely that you could accidentally introduce new bugs when deploying new assemblies than editing .config files. If you work in a shop where untrustworthy non-programmers are in charge of the config files, having something compiled in does reduce the chance of entering bad data.
Database config table - Fetching configuration data from a database is more complicated than retrieving it from a config file. Plus, you have to be careful about data locks and other DB goodness. However, if you need to edit settings at runtime without triggering app pool recycling (unlikely), this is your best bet.
XML file - It's easier to use web.config, but this allows you to deploy a file independent of the web.config so it is less-likely to contain potentially-hazardous side-effects.
Well, option 4 (web.config) is safer than option 2 (xml). A .config can't be downloaded so easily.
For the rest it depends a little, there is no 'right' way but i would use a web.config unless there is a really good reason not to. Web.config is not just for 'deployment related' stuff.
1.- Use DB config table when you want to change parameters without having to restart your application. Prefer its usage.
2.- Use xml file. If your application is XML oriented.
3.- Simple constants file. This should not have parameters, constants are not parameters.
4.- web.config. Use appSettings items for storing simple values that does not change continuously (DBConnectionTimeout, DBCommandTimeout, PageSize etc..), use customized sectionGroup for more complex parameters.
Here is a simple configuration table definition:
CREATE TABLE ctr_group_parameters (
option varchar(50) NOT NULL,
id_group int NOT NULL,
description varchar(100) NOT NULL,
value varchar(200) NOT NULL,
PRIMARY KEY CLUSTERED (option, id_group) )
If these are settings that wouldn't be updated often, I like using web.config. If they are updated a bit more often, I'd think about using a database table.
I'd use the web.config for stuff you know never changes except when it changes along with application logic. For stuff that may need to change independently of code (like $ charges) you may want to use a database.
i want to know that why do we add an app.config file in c# projects for the connection string if our work is also access able by simple combining the command text and data adapter ..
what is the functionality of this .xml file?
It allows you to change the runtime parameters (things like connection strings, for example if the database gets moved onto a different server) at runtime without having to recompile and re-distribute the application.
connection string is always required. sometimes it is passed implicitly so you don't notice it. app.config is just a place where they can be stored so you can change them when server name or other parameters change
Having the configuration data (including the Connection string) stored in a separate file form your binary, allows you the freedom to update the values stored in the configuration without having to recompile your application.
This can be great if for instance your application wants to talk to different databases for dev - Test and Production.
You do not have to use the app.config xml structure, its just a convenience that the .net framework provide code to read/update.
You could also store configuration data in your own format, pull it from Active Directory, or a dedicated configuration service.