Am working on a business layer for a complex web application and am temporary using the Dynamic Data Site functionality to allow data to be entered into the many tables that I need to maintain. I don't want to spend too much time on this DDS since the business layer needs to be finished first. Once the business layer is done, it gets shipped to someone else to add a better user interface.
However, while the DDS offers a lot of functionality in a very easy way, I just want to extend it with an "Export to XML" button or link. (And I'll probably will add an "Export to Excel" button later.)
So, has anyone done something like this already? What would be the easiest way to implement this in .NET, without rewriting the DDS?
(I use an Entity model for the database connection and much of the business layer is built upon this entity model. Once the business layer is finished, the real GUI interface will be developed for this web application but for now I just need a good way to input/output this data.)
I have no problems converting an entity set to XML. That's the easy part. My problem lies in expanding "ListDetails.aspx" with an additional button which the user can click. Once clicked, it should export the dataset to XML. To make it interesting, if the user has set one or more filters, it should only export those filtered records.
I think I'll have to look into the "GridDataSource" object that's on this page and experiment with it. Will it return the whole table or just the filtered dataset? Or just the records that are on the current page?
Now, with export, I just want a dump of the dataset to XML. Basically, what you see should end up in the final XML. If I have access to the filtered dataset then creating the XML would be easy. (And creating the Excel sheet on top of that is a piece of cake too.) In general, the export is just used to help develop the business layer of a project I'm working on. Most of the code is business logic that will be used in other (web/desktop) client applications but while the project is still in progress, the DDS is needed for easier data entry for the project. Once it's finished (a gazillion years from now, I guess) then the DDS won't be used anymore. Nor would we use the XML exports or the export sheets. But for now, those exports are useful to evaluate the data. (Since I still have to develop the more complex analysis tools.)
This is fairly straightforward, you've got to address a couple of issues:
Providing a means to trigger the export
Generating the XML
Making the XML available (as a link) for download - assuming that that's what you want to do.
There's a slightly less straightforward alternative which is to create a service to generate and return the XML.
In terms of the first - there's nothing to stop you editing either the master page or the default page to add your own functionaliy i.e. a button or a link to an XML gen page.
In terms of the second - Linq makes it almost trivial to generate XML from your Entity model.
Once you've got your XML you've got various options the key here is that you can add your own pages to the site if you want - the magic in Dynamic Data is simply a starting point not the final product (although if it does all you need then you can walk away with a smile on your face).
I appreciate that these are generic answers but its a fairly generic question and the details of implementation would be better addressed by more specific pages.
In terms of specific, I have a Dyanmic data site which needs to generate XML, the first iteration was simply a button on the default page that saved a file to disk (one file name, one file format, click, gen, save, done). The reason for the XML was as the source data for another site so I then added a WCF service which exposes the same XML. Total time spent (less a bit for getting my head around WCF) probably less than half a day - most of which has been spent fiddling with the XML output.
Maybe you can do something with FileHelpers.
Related
I realize this is not a very specific question that is open to different opinions, but answering it requires technical expertise that I do not currently have.
My team of 10 people continually maintains and updates a SQL database of approximately 1 million records and 100 fields. We are a market research outfit - most of the data points are modeled assumptions that we need to update frequently as new information becomes available.
We use a .NET web interface to update/insert/delete. However, this interface is clunky and slow. For example:
We cannot copy/paste in a row of numbers; e.g., budgeted amounts across several time periods;
We cannot copy/paste similar dimension values across multiple records;
We cannot create new records and fill it's contents quickly
Cannot assess the effect of your changes on your dataset, as you could with Excel
Most of us are more inclined to navigate data, change values and test our assumptions in Excel, and then go back and make changes in the .NET interface.
My question is:
is it possible for multiple users to simultaneously use Excel as a content management system for a custom SQL database? I would design a workbook with tabs that would be specifically designed to upload to the database, and on other tabs analysts could quickly and easily perform their calculations, copy/paste, etc.
If Excel is not ideal, are there other CMS solutions out there that I could adapt to my database? I was looking at something like this, but I have no idea if it is ideal: http://sqlspreads.com/
If the above is not realistic, are there ways that a .NET CMS interface can be optimized to 1) run queries faster 2) allow copy/paste, or 3) other optimization?
Having multiple people working on one Excel sheet won't work. What you want to do it create an Excel template that is the same for everyone. Then you have have everyone entering data in on their templates. Write a script that takes this template and uploads it to the database table. You can have a template for each table/view and then you have join tables or views to get a bigger picture of all the data.
it's possible to do something like that in Excel - but it's not that easy. I created such a solution for one of my customers. 400 to 500 users are downloading data from a MS-SQL server into Excel. The data can be changed there and uploaded back to the server then. This works for pure line by line as well as for more complex reporting decks. But as I said: to built such a solution isn't a quick one.
Personally I would try to improve the .NET frontend. Because if it is so slow then I would guess you are doing something wrong there. On the end of the day it doesn't make such a great difference what kind of frontend you use. You will always face similar problems.
Been thinking about this some time: Let's say I have a application where you can add and use reminders.
What is the best way to store this? In the past I've always used a textfile but it can get problematic if I later want to add another "field" to each reminder in the textfile. Let's say I add an feature for recurring reminders.
What is the most volatile way? Text? Xml? Json? SQLite?
Use a database. Adding another field is as simple as adding another column to a table.
MySQL is a solid query language and easy to pick up for beginners. When I started out, I watched (and really enjoyed) this tutorial series:
https://www.youtube.com/watch?v=6pbxQQG25Jw
If you ever make something that needs lots of scalability, you might want to look into PostgreSQL.
SQLite becomes a better option as your data model becomes more complex. The upgrade process (changing, adding, and removing tables) is a bit of work, and is required for your code to even refer to a new field in a query.
XML And JSON have the advantage of having parsers built into the standard libraries for most platforms these days, so you don't have to fix your parser every time you change your data model (as you would with plain text). XML can validate your model and let you know if the file does not comply with your model. JSON is really just a serialization protocol and doesn't provide anything in terms of model validation, which makes it the most flexible of the plain text options (IMO).
In terms of updating your model, your code should read in the file and allow for the new field to be missing or empty. If the field is mandatory, you should provide a default value and then write your model back out to the file so it's good to go the next time. This process is roughly the same for SQLite, but is just a bit more involved in terms of what you have to do to upgrade your model.
I'm new to windows app and I would like to know what the best way to save a small amount of data, like 1 value a day.
I'm going for the text file because it's easy, but I know i could use MS Access.
Do you have other option ? Faster or better ?
Since you are already considering using a MS Access database, I would recommend using SQLite. Here's a quote from their site (SQLite Home Page):
SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.
It is really very easy to use - no installations required, you simply need to reference a DLL.
If you need to read it then use a plain text file.
If you need to read the values back into the application then serialize to an XML or binary file by making your user data serializable possibly by having a List of values in your object.
How do you want to use the data? Do you just want to look at it once in awhile? Do you plan to analyze it in a spreadsheet? Etc. Based upon what you say so far, I would just use a text file, one value per line. Even if later you wanted to do more with it, it's easy to import into spreadsheets, etc. If the daily data is a little more complicated (maybe a couple of different values for things each day), you might consider something like YAML.
Why stray from the path? XML gives you the ability to expand on it later without having to rethink everything.
Its mainly dependent upon the complexity of the data that you want to store. If its just DateTime some other simple built in type you would be able to recreate that object as a strongly typed one easily. But in case if its more complicated I would suggest you to create a serializable class (link on how to create such class is here) and then use one of Binary or SOAP serializations based on the size, security and other such needs. I am suggesting this as it would be best to be able to recreate objects as strongly typed ones from a flat file rather than just trying to parse what's there in the flat file.
Please let me know in case you need more clarity.
Thanks,
Sai Pavan
I work on a web application that modifies a XML document that is stored in a database. It is made to mimic exactly like any program does when you click the "preferences" option in the menu. The XML document is read by a local client application and any changes are reflected in the local client.
My web app has 3 tiers I guess you would say with the aspx page being the "view", a service layer where I validate / process all user input, and a data layer where I update the XML document.
For each page of settings, I had been recursively traversing all the controls on the page and if I came to one that I wanted to work on (checkbox, textbox, ...) I added it to a IList and then sent that IList to the service layer where I then had to pull the control out of the list so I could work on it.
I noticed this seemed to be a bit slow so I profiled the page and basically the LINQ to Objects queries that I had been using tend to eat up a ton of time.
(CheckBox)lstControls.Where(x => x.ID == "some_id").SingleOrDefault();
I then switched to manually adding the controls on the page to a IList and then pulling them out in the service layer by indexer in the order they were put in. This is fugly and completely dependent on you not screwing up the index of the control you are looking for.
Finally, this breaks the rule of mixing elements from the view with the service layer or data layer. I know I should be working with data only, but I am at a loss of how to efficiently do this.
Each settings page has from one to thirty controls that need to be processed. How do I get all the data from the controls to the service layer without sending the actual controls?
Thanks for the help....
You might get into a better situation if you gather the data, the stuff you are actually interested in, into some object structure with some semantics that will help you structure what is passed on to the next layer. The keyword "Databinding" should also help you to just get to the values that were entered. There is no need to pass any controls back to the next layer..
I am creating an RSS reader as a hobby project, and at the point where the user is adding his own URL's.
I was thinking of two things.
A plaintext file where each url is a single line
SQLite where i can have unique ID's and descriptions following the URL
Is the SQLite idea to much of an overhead or is there a better way to do things like this?
What about as an OPML file? It's XML, so if you needed to store more data then the OPML specification supplies, you can always add your own namespace.
Additionally, importing and exporting from other RSS readers is all done via OPML. Often there is library support for it. If you're interested in having users switch then you have to support OPML. Thansk to jamesh for bringing that point up.
Why not XML?
If you're dealing with RSS anyway you mayaswell :)
Do you plan just to store URLs? Or you plan to add data like last_fetch_time or so?
If it's just a simple URL list that your program will read line-by-line and download data, store it in a file or even better in some serialized object written to a file.
If you plan to extend it, add comments/time of last fetch, etc, I'd go for SQLite, it's not that much overhead.
If it's a single user application that only has one instance, SQLite might be overkill.
You've got a few options as I see it:
SQLite / Database layer. Increases the dependencies your code needs to run. But allows concurrent access
Roll your own text parser. Complexity increases as you want to save more data and you're re-inventing the wheel. Less dependency and initially, while your data is simple, it's trivial for a novice user of your application to edit.
Use XML. It's well formed & defined and text editable. Could be overkill for storing just a URL though.
Use something like pickle to serialize your objects and save them to disk. Changes to your data structure means "upgrading" the pickle files. Not very intuitive to edit for a novice user, but extremely easy to implement.
I'd go with the XML text file option. You can use the XSD tool built into Visual Studio to create a DataTable out of the XML data, and it easily serializes back into the file when needed.
The other caveat is that I'm sure you're going to want the end user to be able to categorize their RSS feeds and be able to potentially search/sort them, and having that kind of datatable style will help with this.
You'll get easy file storage and access, the benefit of a "database" structure, but not quite the overhead of SQLite.