I have been asked to create a project which involves loading profiles into a UI in which the user can edit the values. I need to be able to load data from a file within the project and allow the user to make chnages and save back to that file.
All of this has to be contained within an executable but I am unsure of the best way to approach this, I was think of using an XML file with an XML structure or a text file and just string split on it or even a resources file and just call out to it.
I thought I would put my problem up on here and see what the community suggest, thanks!
Embedded resources are not intended to be changed during runtime. A database is really easy to auto-create these days using code-first EF, but a file containing XML or JSON would also be a good option (as there are third-party libraries to help you parse the result). Hand-rolling your own string.split solution is not recommended (because if requirements get more complex in the future, your code may become unmanageable)
Related
I need to restore a certain file hierarchy in a folder, after it gets deleted (yeah, don't ask).
For now I imagine it as a simple application that gets run by Windows Task Scheduler. While there are some ways to achieve that effect, I wanted to create a simple single exe.
So I put my structure into my project, and set all files Build Action to "Embedded resource". I can sort of access them through Assembly.GetExecutingAssembly().GetManifestResourceNames() and Assembly.GetExecutingAssembly().GetManifestResourceStream(name), however I don't see any simple way to preserve hierarchy like that.
While I'm solving a real problem, the question is more academic in nature - I don't need anything convoluted, like parsing resource name to determine what hierarchy it resulted from. My file structure actually is just 4 files in two folders, if push comes to shove I can just write everything out manually.
I'm sure there should be a simple way to just say "Hey, here's how those files should be arranged, repeat". Maybe resources are a wrong mechanism?
You're right, you can't. Because resource names are identifiers, some characters are replaced during the build and you can't store empty folders either You can however build a Zip file from the structure embed that single file and extract it when needed - with one single call if you want. The framework has built-in zip support. Please note however that the ZipFile can't be accessed concurrently only sequentially as there is only a single inner state.
I have a list of store information.
Each store has a region, a zone, and a store number.
The way I've been doing this now is:
I have a Store class, and a List with elements type Store.
In each application, I have to add this long list of StoreList.Add(new Store() { ... }), which looks bad, is sloppy, and totally not convenient. So I was looking for a way to use this information across multiple solutions/projects.
I don't want to use a database because I don't really want additional overhead in what could be simple scripts. Is a DLL something I would use in this circumstance?
You said you don't want to use database, but probably its not a bad choice. You can store the information in a XML file and read that on application startup. Having such information in a class and then dll, would complicate things. If you have to modify a store number, you have to deploy that dll on computers running your application, although modification in XML would be required on computers as well but it would be easier IMO.
Also if you have that information in some central database and loads up that information on application start event, it would provide you a much better option of maintaining your application and having lesser changes in client side / deployment.
The problem is not whether you want a database or not, but if you need to store your data once your application closes.
Now, you can use a database (could be an embedded one) or a file (xml most probably).
If all your data is stored in code (not the best option really) then yes, you can move that code to a class library project and distribute it wherever you need it.
But still, at the very least this is what i'd do
Move your list items to an xml file
Create a class that reads this file, and loads it into the list
Add the xml file to your project and mark it as an embedded resource (so it'll be packed with the dll)
You can read the xml file from the assembly directly (check here on SO how to do it)
Hope that helps
I am building a web application that will generate charts and graphs using a 3rd party charting component. This charting component requires it receive an XML file containing the design parameters and data in order to render the chart. The application may render up to 10 to 20 charts per page view. I am looking for suggestions for the most efficient way to handle this.
I need to load XML templates, of which there will be about 15-20, one for each chart type definition. With the templates loaded, I will them add the chart specific data and send it off to the charting component for rendering. Some of the possible ways of handling this off the top of my head include ->
Build each XML template in code, using StringBuilder
Build each XML template in code, using one of the .NET XML classes
Store each XML template in a file, load it from the disk on demand
Store each XML template in a file, load them all at once on application start
Storing the XML templates in files would greatly simplify the development processes for me, but I don't know what kind of performance hit I would take, especially if I was continually reading them off the disk. It seems like option 4 would be the better way to go, but I'm not quite sure the best practice way to implement that solution.
So.. any thoughts out there?
I'm just taking a crack at it but I'd save the templates into a constant like so and then use string.format to substitute any values and convert to XML file and pass it along to the 3rd party component.
const string cChart1 = #"<chart type='pie'>
<total>{0}</total>
<sections count={1}>
<section>{2}</section>
<section>{3}</section>
<section>{4}</section>
</section>
</chart>";
XmlDocument xmlChart1 = new XmlDocument();
xmlChart1.LoadXML(String.format(cChart1, somevalue1, somevalue2, somevalue3, somevalue4, somevalue5));
3rdPartyChartComponent cc = new 3rdPartyChartComponent(xmlChart1);
Thanks for your suggestions everyone.
I created a test application that ran x number of trials for each of the suggested methods to see which performed best. As it turns out, building the XML string directly using StringBuilder was orders of magnitude faster, unsurprisingly.
Involving an XmlDocument in any way greatly reduced performance. It should be noted that my results were based off of running thousands of trials for each method... but in a practical sense, any of these method are fast enough to do the job right, in my opinion.
Of course, building everything using StringBuilder is a bit on the messy side. I like Jarealist's suggestion, it's a lot easier on the eyes, and if I handle the XML as a string throughout rather than loading it into an XmlDocument, its one of the fastest ways to go.
Are the same templates used more than once? You could store the template as a static variable. Then add a property getter that builds the template (I would probably use your #2) if it hasn't yet been created, and then return it.
This would impose a performance hit the first time the template is used and be very fast after that.
I am pretty sure you can tell the compiler to bundle those XML files inside your CLR exe. Reading from these would not imply a noticeable performance hit as they would be already in memory. You will need to research a bit as i cant get the code out of my head right now, too sleepy.
EDIT.
http://msdn.microsoft.com/en-us/library/f45fce5x(v=vs.100).aspx - More info on the subject.
Another benefit from using this approach is that the CLR can guarantee the readability and existance of those files, else your executable will be corrupt and wont run.
My question relates to the performance implications of reading application configuration data from an XML file.
I am building an application that lists information from a database and needs to know how to display the lists, depending on the types of data returned.
This is difficult to explain, but basically I would like to have an XML config file that lists the types and describes how to display them. This will allow me to change the display methods without re-compiling the application.
My question is really around performance. Given that my application will need to use this data many times during each page load...
Should I be reading directly from the XML file and parse it each time I need it?
Or should I cache the XML object and parse it each time I need it?
Or should I parse the XML once, generate some sort of object and cache that object?
My guess is option 3, but I'm basically fishing for best practice around this.
Thanks.
There is already a convention for this, called the App.config file.
It is XML, and Visual Studio has tooling support for it.
My suggestion is: Don't reinvent the wheel, if you can help it.
Now, given that your format is too complex for that, you probably want to go with option 3, but load it lazily.
My application has historically used an ini file on the same file server as the data it consumes is located to store per user settings so that they roam if the user logs on from multiple computers. To do this we had a file that looked like:
[domain\username1]
value1=foo
value2=bar
[domain\username2]
value1=foo
value2=baz
For this release we're trying to migrate away from using ini files due to limitations in the win32 ini read/write functions without having to write a custom ini file parser.
I've looked at app.config and user settings files and neither appear to be suitable. The former needs to be in the same folder as the executable, and the latter doesn't provide any means to create new values at runtime.
Is there a built in option I'm missing, or is my best path to write a preferences class of my own and use the framework's XML serialization to write it out?
I have found that the fastest way here is to just create an XML file that does what you want, then use XSD.exe to create a class and serialize the data. It is fast, and a few lines of code and works quite well.
Have you not checked out or have heard of nini which is a third party ini handler. I found it quite easy to use and simple in reading/writing to ini file.
For your benefit, it would mean very little changes, and easier to use.
The conversion from ini to another format needs to be weighed up, like the code impact, ease of programming (nitpicky aside, changing the code to use xml may be easy but it is limiting in that you cannot write to it). What would be the benefit in ripping out the ini codes and replace it with xml is a question you have to decide?
There may well be a knock on effect such as having to change it and adapt the code...but... for the for-seeable time, sure, ini is a bit outdated and old, but it is still in use, I cannot see Microsoft dropping the ini API support as it is very much alive and in use behind the scenes for driver installation...think of inf files used to specify where the drivers go and how is it installed...it is here to stay as the manufacturers of drivers have adopted it and is de-facto standard way of driver distribution...
Hope this helps,
Best regards,
Tom.