I'm new to Flex, and I'm wondering about the best practices when it comes to getting data from a database and displaying it in a Flex (Flash) swf. Currently I have some C# code that gets the data from the DB and saves it to an XML file on my site. Then the .swf reads that xml file.
Is that the best way to do it, or is there a better or more standardized way? Thanks
protected void Page_Load(object sender, EventArgs e)
{
DataTable _dt = new DataTable();
_dt = ProductList.GetProductssForAdmin(10);
_dt.TableName = "Products";
_dt.WriteXml(Server.MapPath("xml/Flex.xml"), false);
}
You really should use WebORB or FluorineFX to achieve this. It sends binary data(amf) and it's way more performant. You can map flex classes to .net classes which makes it all very easy!
If you install WebORB or FluorineFX, you get a load of examples + very clear documentation.
I really wouldn't recommend using xml.
I think the answer really depends on a lot of factors. Although a using a three tiered approach (Database -> Web Service -> Frontend) is the SOP, consider the following:
1) The quantity of data: If your application is using a large amount of data, or a varying subset of a larger database, then using a three tiered approach is going to be best. However if it's a small amount of data then a flat file is a simple a straightforward solution.
2) How often does the data change: If it changes a lot, then the three tiered approach is best. You might even consider a solution outside of ASP.NET using Livecycle or Blaze if the data is changing very often and you want to push changes to the Flex frontend. However if the data you are using is updated infrequently, then your approach is again, simple and straightforward.
3) Security: Using an XML file is a pretty secure solution. It is disconnected from your database, and short of someone gaining write access to your web server the flow of data is going to be one way. However, if you create a web service and connect it to your database, you have to take steps to ensure the security of your data from SQL injection and other attacks. If this is sensitive data (as if there is any other kind) and you aren't experienced in creating a secure database service, you may want to stick with your current system.
That said my work almost always requires a three tiered approach, and it is the most powerful way to go. Just be sure that if you go that route you've considered all the factors, number 3 in particular.
EDIT:
There should really be another item in that list, which is closely related to number 1:
4) What are you doing with the data: If you are just rendering the same set of data as a table in the application or something along those lines then an XML file is a decent solution. If you are doing a lot of XPath type queries on the returned XML before it is being used then the three tiered approach has the advantage.
Another perfectly viable option that preserves the separation of concerns is to use JSON rather than XML. It's pretty well supported on both sides of the connection (web service & client), and it simplifies the marshaling and un-marshaling process in Flex quite a bit.
The best way to do it is to create a web service. In Visual Studio, create a new Web project, and select ASP.NET Web Service Application.
The following tutorial should help you get started in writing a web service using ASP.NET.
http://www.15seconds.com/Issue/010430.htm
Also, here's how to consume a web service with Flex.
http://www.adobe.com/devnet/flex/articles/flexbuilder_ws.html
Related
I had a bit of a shock recently when thinking about combining a service oriented architecture with a brilliant UI which leverages SQL to optimize performance when querying data.
The DevExpress grid view for ASP.NET, for example, is so cool that it delegates all filtering, sorting and paging logic to the database server. But this presumes that the data is retrieved from a SQL-able database server.
What if I want to introduce a web service layer between the database and UI layers, and to have the UI use the web services to query the data?
How can I design the web services and the UI such that I can pass filtering requests from the UI via the web services to the database?
Do I need to provide a List QueryData(string sqlQuery) style web service and have to parse the SQL string on my own to guarantee security/access restriction?
Or is there any good framework or design guideline that takes this burden from me?
This must be a very common problem, and I am sure that it has been solved relatively adequately already, has it?
I am mainly interested in a .NET/C#-based or -compatible solution.
Edit: I've found OData and Microsoft WCF Data Services. If I got it right, an OData-based application could look as follows:
User ---/Give me Page 1 (records 1..10)/---> ASP.NET Server Control (of course, via HTTP)
ASP.NET Server Control ---/LINQ Query/---> Data service client
Data service client ---/OData Query/---> WCF Data Service
WCF Data Service ---/LINQ Query/---> Entity Framework
Entity Framework ---/SQL Query/---> Database
If I got this right, my DevExpress server control should be able to delegate a filtering request (e.g. give me the top 10 only) through all these layers down to the database which then applies its indexes etc. in order to perform that query.
Is that right?
Edit: It is a joy to see this thread coming to life :-) It is hard to decide on what answer to accept because all seem equally good to me...
Really interesting question! I don't think there's a right or wrong answer, but I think you can establish some architectural principles.
Firstly, "Service Oriented Architecture" is an architectural style that requires you to expose business services for consumption by other applications. Running a database query is not a service - in my opinion at least. In fact, providing a web service to execute arbitrary SQL is probably an anti-pattern - you would bypass the security model most database servers provide, you'd have no control over the queries - it's relatively easy to write a syntactically correct "select" query which cripples your database (Cartesian joins are my favourite), and the overhead of the web service protocol would make this approach several times slower than just querying the database through normal access routes - LINQ or whatever.
So, let's assume you accept that point of view - what is the solution to the problem?
Firstly, if you want the productivity of using the DevExpress grid, you probably should work in the way DevExpress want you to work - if that means querying the database directly, that's by far the best way to go. If you want to move to a SOA, and the DevExpress grid doesn't support that, it's time to find a new grid control, rather than tailor your entire enterprise architecture to a relatively minor component.
Secondly - structurally, where should you do your sorting, filtering etc? This is an easy concept in SQL, but rather unpleasant when trying to translate it to a web service specification - you quickly end up with an incomprehensible method signature ("getAccountDataForUser(userID, bool sortByDate, bool sortByValue, bool filterZeros, bool filterTransfers)").
On the other hand, performing the filtering and sorting on the client is messy and slow.
My recommendation would be to look at the Specification Pattern - this allows you to have clean method signatures, but specify the desired sorting and ordering in a consistent way.
Implementing the List QueryData(string sqlQuery) will open you up to a near infinite number of security problems.
If you need to filter based on security access, then the OData implementation will not be trivial either, you need to setup proper authorization/authentication on the WCF service so that you could further filter the OData query based on the authenticated user data.
The easiest way to implement server side data operations when the data is retrieved from a WCF service would be to intercept the Grid's sort/filter operations in the code behind, and then call a specialized method on the WCF service based on what the user is doing.
"This must be a very common problem, and I am sure that it has been
solved relatively adequately already, has it?"
Given the number of skinned cats laying around the developer world, I'd have to say no.
WCF Data Services offers the best solution I've found so far, but there authentication and authorization can be tricky. There is a decent post covering the server-side issues around this at http://blogs.msdn.com/b/astoriateam/archive/2010/07/19/odata-and-authentication-part-4-server-side-hooks.aspx. Setting this up isn't easy, but it does work well.
I have a project which we are thinking of optimizing some parts of the program.
It is basically a 3 tier hierarchy structure and below will be roughly how we structured.
UI - aspx and aspx.cs
Business Logic- Web Services
Data Access- a separate class residing the web service project.
Example:
The practice now is that when we retrieve data, we retrieve in terms of dataset from the web service and return it to the UI to process the displaying of data. In order to make changes to the database, the changed dataset is passed back to the web service. For small number of results, it would not pose much issue, but when the result is huge, web service will also be passing a larger xml to and forth, which greatly decrease performance.
So does anyone happen be using this type of structure and have a better way of processing database results? Right now, this practice is used in all CRUD, so the idea that came to me is for create and delete, or maybe even update, we can skip the passing of dataset, and use a linear command, but I am not sure is this a good method
If by dataset you mean DataSet then this is something that should never be passed to and from a web service. I would recommend you using POCO classes when communicating with the service. A DataSet already does XML serialization/deserialization internally and when you send it to a web service this serialization/deserialization will occur twice. Another tip is not to resend the entire dataset back to the web service but only what has changed in between the calls to reduce the network traffic.
Rule of thumb: In web applications you should exchange only that data between client and server which is needed. I mean all filtering, etc should be done server side.
Some ideas are: Employ paging, avoid datasets, ask for only that information to your WS which you intend to show!
What is the most effective way to sync two identically structured DataSets using a Web Service?
The design I use at the moment is simple without a Web Service. All data iscached on the Client, and it will only update data from the MySQL database if an update has been done, this is determined by a timestamp.
If possible I want to keep the same simple design, but add a Web Service in the middle, to allow easier access to the database over our limited VPN.
Best Regards, John
That's one heck of a question, but something I'm doing myself too. Easiest way I guess would be to add a "saved version" property. If it really is a simple design then you could just re-write only the DAL code to get things working for a web service. In fact, if the WSDL is done right, you may only need to make very minor adjustments (especially if the DB was previously designed using EF).
You say you want to sync two datasets simultaneously, but the question I guess is why? And which two? Do you have two web services, or are you wanting to sync data to both the local cache and the online web service (MSSQL db?) simultaneously?
Ok, this is very "generic" question. We currently have a SQL Server database for which we need to develop an application in ASP.NET with will contain all the business logic in C# Web Services.
The thing is that, architecturally speaking, I'm not sure how to design the web service and the data management. There are many things to consider :
We need have very rapid access to data. Right now, we have over a million "sales" and "purchases" record from which we need to often calculate and load the current stock for a given day according to a serie of parameter. I'm not sure how we should preload the data and keep the data in the Web Service. Doing a stock calculation within a SQL query will be very lengthy. They currently have a stock calculation application that preloads all sales and purchases for the day and afterwards calculate the stock on the code-side.
We want to develop powerful reporting tools. We want to implement a "pivot table" but not sure how to implement it and have good performances.
For the reasons above, I'm not sure how to design the data model.
How would you manage the display of the current stock, considering that "stock" is actually purchases - sales and that you have to consider all rows to calculate it ? Would you cache "stock" data in the database to optimize performances, even though its redundant data ?
Anybody can give me any guidelines on how to start, or from their personnal experiences (what have you done in the past ?)
I'm not sure if it's possible to make a bounty even though the question is new (I'd put 300 rep on it, since I really need something). If you know how, let me know.
Thanks
The first suggestion is to not use legacy ASMX web services. Use WCF, which Microsoft says should be used for all new web service development.
Second, are you sure you can't optimize the database, or else place it on faster hardware, or nearer to the web server?
I don't know that you're going to get that much data in memory at once. If you could, then you could use a DataSet and use LINQ to DataSets for queries against it.
I hope I hope I'm misunderstanding what you wrote, but if by
contain all the business logic in C# Web Services
you mean something like this then you're already headed in the anti-pattern direction. Accessing your data from an ASP.NET application over web-services would just cause you to incur the serialization/deserialization penalty for pretty much no gain.
A better approach would be to organize services you want to make available into a common layer that your applications are built on and access them directly from your ASP.NET application and maybe also expose them as Web Services to allow external sources to consume this data.
You could also look into exposing data that is expensive to compute using a data warehouse that is updated at regular intervals (once or a couple of times/day). This would help with getting better read performance out of data (as long as you're willing to accept data being a bit stale).
Is that the kind of information you're looking for?
What is the best way to store your Data outside of SharePoint. I want to use the default Edit/View options in SharePoint (though I do plan on extending their functionality). I need to store the data outside of the SharePoint Lists as I am expecting a large record set(150,000 to start with).
I totally agree with GalacticJello, storing data outside of the regular sharepoint content database is at the moment (MOSS 2007) a complete and utter nightmare. MS provided a ExternalStorage provider baseclas for us to override, but there are major cons against using this:
writing and using your own custom ExternalStorage provider implementation is doable, but very difficult
ExternalStorage provider implementations only do just that, making sharepoint store stuff in a different location than the regular content db.
This means that you would need to write your own code to keep the external storage and the list items in sync, and i'm not even mentioning workflows and versioning.
last but not least (and IMHO the worst), creating and using a custom ExternalStorage provider is not web app or site collection targetable, it's usage is farm wide (and there are NO workarounds). So any site collection you create in that farm will have it's doc libs use the external storage provider.
You can store the items in the list, the trick is to create efficient views that return paged data quickly back to the user.
Another option is to use folders to split up the data.
If you really need to store it outside of SharePoint, I would consider waiting for SharePoint 2010 and thier "External Lists" features, as there are a ton of pitfalls and things to consider if you want to mimic that functionality in SharePoint 2007 (been there, done that).
You could create a SQL Data source and use the Data Form Web part to connect it to an edit form etc.:
Data Forms and SQL Server, Part 1
Data Forms and SQL Server, Part 2
Personally I prefer to have the level of control of a totally custom web part.. with this you will not run into limitations eventually.
In this case it sounds like all the elements will be in the same list, otherwise SLAM (free tool on CodePlex) is a very neat data replication tool for related lists.
Based on the comments above it sure looks like a plain ol' ASP.NET page might be the best option, unless there is some good reason why SharePoint must be used.