My Windows service should connect to different Databases and get the data from that (multitenent). and each connection maintain in seperate thread. Is this possible?
Database information is available in XML file.
Does anyone have a suggestion about how this can be done?
Windows services run all of the time and as you have the database details contained within a config file of sorts then you can read the connection string from there.
When structuring the code, a service is no different from a console program, other than those bits necessary for the ServiceManager to pick up on.
So structure the code such that the main logic is database agnostic i.e. it doesn't care whats beyond the datalayer interface only that it knows what the interface is.
Check out Repository and factory patterns. These will be of help. You can then create a concrete instance of the correct database class at runtime, by reading what the config file says.
Remember that the service will always run (unless set to be manually triggered) and have it be able to fail quietly if it doesn't find the config file.
Related
What is the best way to use a Database in an Open-Source Program which I want to publish on GitHub?
I've had a problem with publishing my programs on GitHub because you were able to see the Connection String. That allowed you to edit the Database how you wanted to. Is there a way to encrypt the ConnectionString when I upload it to GitHub? Is there another way to solve this problem?
Encryption is only as reliable as the way you store the key, wich would have to be as public as anything else used in the code. The requirements of Secrecy and publishing on GitHub are inherently at odds.
One way would be to store stuff like the connecting string in a configuration file that you do not share on github. Or use a local Network only Database with default User values, wich do not help any attacker on your Production Systems.
If for some odd reason access to the same shared datasource is required across all compilations/installations, you could hide the Database behind a WebService whose code you do not share. As the programm only needs to worry about accessing a WebService, you would not need any DB values. Or even wich DB is used in the backend.
We are moving database from one server to another. There are many connection strings of applications that needs to changed due to this. Is there any generic way where we can keep the connection string so that if we move the database again then this issue doesn't arise??
There are so many ways to resolve this problem.
Ultimately what it sounds like you want to do is centralize your database connection strings in such a way that a database migration is (mostly) transparent to your application. I can think of a few options here:
Use a "control database" that houses your connection strings and configurations. If you migrate to a new database server, you only have to update a single connection string in your application, and perform data updates for everything else. This is what I personally use.
Use a central XML configuration file that is parsed on application startup.
Use SQL Server Aliases and/or add additional IPs to the machine that you can migrate between servers. This way when you move to a new database server you can still bring along the existing aliases/IPs to that server (unless they need to run in parallel of course) and theoretically not need to update anything in your code, provided that you've referenced the appropriate aliases. See here for more info: https://dba.stackexchange.com/questions/56642/how-to-create-a-server-alias-in-sql-server-2012
Over here we ultimately went with option 1 because that gave us more flexibility and reliability than an XML configuration file (#2) and required less configuration and special cases to be documented with our DBAs, since we have no ownership of any database servers outside of our DEV environment.
Have the connection string in an xml file and read the xml file and get the connection string from it. You only need to change the connection string in the xml file and not in the published code. By the way you can have multiple connection strings for Debug and Release modes and make your application choose it.
You could store them in a database. ^_^
Jokes aside, I do not have experience with this myself, but using an Alias sound like it might suit you best:
http://blog.idera.com/sharepoint/performance-webcasts/plan-your-sharepoint-farm-right-with-a-sql-server-alias/
First, you can store your connection strings in external file (custom storage or .config file) - so you will be able to change them without recompiling the code.
Second, you can use domain name instead of IP address
And third, you can store your connection strings in parts and build them in runtime by ConnectionStringBuilder - so you can change only server part.
Hi guys I need to exposed my application configuration files that can be edited on the fly and some reports on a web page. All of my application are either console / win forms app.
I'm planning to use XSLT and http listener class of .net for the implementation is this a good idea to start or not? or is there any implementation of this kind ?
Editing web.config or app.config should be avoided in lieu of storing such settings that need to change dynamically in another data store, like a database. If you store such settings in a database you can easily create a UI to administer such settings.
If I'm understanding you correctly then what you want is a web interface that users can use to modify some configuration properties and/or generate some reports based on data that is being used/generated by one or more desktop applications.
You need to define a central database, like SQL Server or something similar. Your desktop applications then need to store their data in this database. Then it would be super easy to build a web user interface that could also use the same database and view/manipulate data.
You're question is kind of vague so for now that's the best answer I can give you. I'm thinking you need to re-think your architecture.
I have windows forms app and server side services based on ADO.NET dataservice.
Is it a bad practice to create and initialize one static dataservice client in windows app and use it across the program? For example i can use it in all opened forms(which have bindings to service's datacontext's objects) to call SaveChanges() and not loose tracking.. Or creating a service client instance for every new form is better(because i think after some time with one static client there will be huge memory growth)? But when i create a new client for every form, i assume i create a new connection to the service every time..
May be im wrong and a bit confused about using services in client application. Please help me to understand the right way it works.
Actually the DataServiceContext class doesn't create a connection to the service. The OData protocol it uses is based on REST and as such it's stateless. So creation of the context alone doesn't even touch the service. Each operation (query, save changes) issues a separate and standalone request to the service. From the point of view of the service it's just number of unrelated requests.
As noted above it's usually a good idea to have a separate context for each "section" of your application. What is that exactly depends on your app. If you are not going to load/track huge number of entities (1000s at least) then one context might be fine. On the other hand several contexts give you the ability to "cancel" the update operations by simply droping the context and not calling SaveChanges, which might be handy in some applications.
I would say: It depends. ;) Well your problem is familiar to the decison you have to make, when using directly Entity Framework. So I recommend you to search for such articles and extract their point.
My own experience with EF tells me, that an application with several workflows should have a context for every workflow. Especially, when more than one workflow can be started at the same time and the user can switch between them.
If the application is simple it's proper approach to use only one context.
I'm currently involved in a very large supply chain management software system internal to where I'm employed. The system's UI is currently only implemented through ASP.NET, but we're in development of Windows Forms and Windows Mobile Compact interfaces as well. We have a pretty good setup in terms of separating the interface, business, and data access layers, so we have successfully shared across multiple platforms. However, we have some security concerns for when we distribute our client-based interfaces to the customer.
Several of our data access libraries are distributed with the executable. Simply opening the compiled assembly in Notepad gives full view to any queries within.
For example, let's say we have a class called "User" who implements the method "GetName" as:
select name from user where id = #id
The problem is that anyone keen enough to open the compiled assembly in Notepad can now see column and table names. Sure, they may not have access to these, but I'd still rather not expose the schema if I don't have to.
The above is just a simple example. Am I going about the thought process incorrectly, or is there a way to protect our queries? (I'd rather not resort to using stored procedures for everything.)
I've thought of forcing out data access layer to be remote and communicating from the business layer via web services so that all database related information is on our internal server that we can protect easier.
If you want to remove the sql from the src, then you are looking at another layer like web services. While that hides your sql, the services themselves must now be public. So while those who peek cannot see the db schema, they can still see the data layout.
What the web services allow for is an easier way to make schema changes since now you just have to make sure the data output is always the same. It also allows for you to move, rename, and/or perform other maintanence with the schema's dbs. Finally, it would better allow you to pool db connections local instead of over a network and have more processing run at the server.