.Net 应用程序：数据库连接最佳实践

Question

I am a beginner in programming in the sense that I have 0 expérience: I have never developped any application. A few months ago, I started developping a desktop app in WPF/C# with a SQL Server Database.

As I am more familiar with Databases, the first thing I did was create my DB and all the tables & relationships. I knew that I didn't want to include my queries in my application so I created 100+ stored procedures containing all the logics that have to be implemented in my app. Now that I have finished creating my UI, I am about to start coding and the first thing I have to do is establish a connection between my app and my DB and I know that it wouldn't be good practice to include my connection string, DB user/passwords in the App.config due to risk of future maintainance problems.

I believe that the best thing to do would be to have a sort of layer between my application and my database where I can store connection informations so that my app can interact with that layer and the layer with the DB. My question is: how do I do that? I have seen answers here that suggests creating a WCF service. This is like a foreign language to me but I am very willing to learn. I would like to have some feedback on whether someone with 0 programming experience can implement such an architecture or should I just give up. Is there no open source documentation that has this type of implementation?

Secondly, are there other best practices that I should be aware of regarding my applications? For instance:

1. I have implemented a RBAC approach but all access controls are implemented in my stored procedures. Is that Ok?

2. Connecting to the app requires a username and a password. Those information are stored in one single table in my DB. I am thinking of encrypting the password field.

3. The app can be distributed to multiple clients. I am thinking of implementing three different DataBases (Test, Accept and Production, probably in different servers as well) and for each client, I will create a specific schema in the DB so that each client has its own objects. This way, there never is interaction between data from different clients. The problem is providing the app to a new client will require customizing everything (schema, tables, procedures, fucntions, ...) but I feel like this can cause maintainance problems as each change will have to be applied accross each client's schema.

4. Regaring DB connection, while it is possible to include a connection string in the App.Config, in Visual Studio, there is also the possibility to directly connect to the DataBase in DataSources. What's the best approach?

I might miss some other things but It would be great to have feedback on those questions.

Answer 1

Now that I have finished creating my UI

Up to reading this I thought you'd finished creating your back end

I know that it wouldn't be good practice to include my connection string, DB user/passwords in the App.config due to risk of future maintainance problems.

If you're not going to store your connection string in the app.config then you need another way of authenticating, such as windows credentials. Or you need to encrypt sections of your app config. It's more about security than future maintenance. If anything not putting db connection details in your app.config will create more maintenance headaches because for the most part things are engineered to expect that that's where they will be. You can store them in aa text file or ask your user for them every time, if you like, of course

I believe that the best thing to do would be to have a sort of layer between my application and my database where I can store connection informations so that my app can interact with that layer and the layer with the DB.

It's not so much about storing connection details; this sounds like you're starting to break into the typical architecture of having a data layer that deals with objects in the database, and a business logic layer that deals with operations the business needs to perform using one or more data layer entities. Creating a new account will require info about the person and the address, and the data layer might reat these as different things, whereas the business layer thinks of them as one thing vital to a particular process

how do I do that?

Most people do it by deferring data related things to a library like EF, that is interested in the db and the entities it contains and modelling them in code.. Then you have a set of classes taht define the operations you will perform to achieve the business goal, and a set of data storage classes that support those operations, and a set of processes for mapping the business objects to the database entity objects; a CreateAccountModel is generated by the UI and passed to a AccountRepository's CreateAccount method; internally the account repository knows about Person objects and Address objects in the DB, via a db context, and will create one of each using the data it finds in the CreateAccountModel. This disconnects the business requirement process of creating an account from the things that store the data. Conceptually you can swap out the database for another that stores Individual and Location instead of Person and Address, and the business layer doesn't care. Read around on the topic; there isn't a right or wrong way to do it so it's not an easy question to present a fact based answer to

I have seen answers here that suggests creating a WCF service

WCF is a framework for webservices; websites that a computer can use instead of a human. You could insert this layer of abstraction for sure but realistically you'd only want to do it if your user interface is somehow very distant from your data storage and processing center, or your business financial model relies on your providing your software as a service to someone. I wouldn't expect a UI that is used locally and has its own DB to need to complexity of being operable over a network, if all it will ever do is call the service on the local machine

should I just give up

It's not a question SO is designed to answer. It's not a question that a seasoned professional asks

Is there no open source documentation that has this type of implementation?

There are millions of projects and thousands of architectures; this should tell you that there is more than one way of doing something and ultimately what is right is subjective/opinion. If it works, and doesn't crash and meets the client's expectations and didn't cost you more to build and maintain than you were paid for it, you could say it was right

Secondly, are there other best practices that I should be aware of regarding my applications?

Probably hundreds of them, but not a question SO is designed to answer

Is that Ok?

Does it meet the criteria for being OK?

Connecting to the app requires a username and a password. Those information are stored in one single table in my DB. I am thinking of encrypting the password field.

Passwords should always be one way encrypted. You take what you're given by the user, apply the same one way encrypt and compare the result with the stored encrypt. Same result, password supplied by the user was good

The app can be distributed to multiple clients. I am thinking of implementing three different DataBases (Test, Accept and Production, probably in different servers as well) and for each client, I will create a specific schema in the DB so that each client has its own objects. This way, there never is interaction between data from different clients. The problem is providing the app to a new client will require customizing everything (schema, tables, procedures, fucntions, ...) but I feel like this can cause maintainance problems as each change will have to be applied accross each client's schema.

Not one we can answer as we don't know your target market's desire for data separation. Most companies that sign up to a service are OK with sharing a DB with other clients, and having separation achieved via some in-table data means such as "clients have their own totally random GUID, then all the accounts have a clientid, all the users have an accountid etc.." so there's a definite hierarchy to the data and a separation.

If you will only have a handful of clients and they demand high degree of separation from peers, you could consider to make a new db (same structure, different data) for each of them, because dealing with multiple different schema with identical tables can be a nightmare

Regaring DB connection, while it is possible to include a connection string in the App.Config, in Visual Studio, there is also the possibility to directly connect to the DataBase in DataSources

There is, but you might find that your connection string ends up stored in a config file anyway. Visual Studio is not usually present on the client machine that runs the app so anything it knows that is vital for the app to work is bundled with the app when you publish

What's the best approach?

Not a question SO is designed to answer, sorry