I have a legacy dot net application (now migrated to .net 2.0).
We need to convert this application to silverlight.
Problem here is the datalayer. All the methods from the datalayer return datasets.
The entire web application is using datasets for databinding.
Now the questions are:
Can I use the same datasets for silverlight pages also?
Or do I have to create a wrapper around the datalayer?
Or do I have to change the entire datalayer architecture (like returning collections etc)?
Please suggest the best possible way.
Thanks,
SNA
Unfortunately, DataSets aren't supported in Silverlight 2 (and afaik aren't coming in Silverlight 3).
I'm going to assume that your current data layer has methods like GetTopCustomers that return DataSets, then the client application can modify that data and re-submit it to a data layer function like UpdateCustomers that takes a DataSet as a parameter and then submits changes to a database. If this is the case I think you'll have a tough time writing a wrapper because you'll be on your own for enforcing referential integrity and tracking changes on the client side. It's certainly possible but I think it'll be more pain than its worth. So imo creating a wrapper around your data layer would be equivalent to changing the entire data layer architecture to return collections, etc.
You best bet for a data layer is .NET RIA Services, which ships sometime in the Silverlight 3 timeframe. It's a huge leap over the current technology, ADO.NET Data Services, in that it adds change tracking and a DataSet-like "context" for the client. It also allows direct sharing of code between ASP.NET (or any part of the full .NET Framework) and Silverlight so your business rules can be run on both the client side and server side. Rewriting your data layer may not sound appealing, but I think it'll spare you much pain and you'll get a huge return if you choose .NET RIA Services. If that choice doesn't fit the other option is to use ADO.NET Data Services to ship the data back and forth (combined with a wrapper for your current data layer) or to write your own custom WCF services to provide CRUD operations (again with a wrapper on your current data layer).
Good luck!
If the goal of your conversion is to create a Silverlight version of your application with the least amount of change to your business logic layer, then a wrapper is your answer.
This is a lot of work in Silverlight V2, as you probably know. If you'd like some detail, here's a blog post. You will end up rolling your own serialize/deserialize/zip/encode layer for transferring the data to your Silverlight app.
Silverlight 3 isn't out yet, but close from the rumors. And this functionality is present in V3 (from what I hear).
Related
We have a mobile application made in VB.NET for Windows CE/Mobile smart devices for shipping/reception operations in a warehouse. This application connects to a SQL Server and extensively uses stored procedures. Since Windows Mobile devices are discontinued and replaced by Android devices, we have to convert our solution to Android, using Visual Studio's Xamarin and C#.
I'm a newbie at Android programming. Is there a way we can connect directly to a SQL Server instance and call a stored procedure from Android? I made some searches and people says it's better to call web services as an intermediary between Android and SQL Server. Is it the best practice?
Thanks for your insight and help
Upgrading Legacy applications can be incredibly complicated depending on the technology and frameworks used.
The first thing I would suggest taking a look at is the Architecture documentation Microsoft produced for Xamarin and Cross-platform frameworks which you can see here
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be an SQLite database but could be implemented with XML files or any other suitable
mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without
exposing implementation details to the caller. For example, the DAL
may contain SQL statements to query or update the data but the
referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic.
Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and
images from remote servers. Encapsulates the networking behavior and
provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the
application (not generally reusable). A good test of whether to place
code in the Application Layer versus the UI Layer is (a) to determine
whether the class has any actual display controls or (b) whether it
could be shared between multiple screens or devices (eg. iPhone and
iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Now you could just simply use the System.Data.SqlClient assembly and fire off stored procedure runs against your database. However a more common approach would to create an REST Api that sits in-between your client and your back-end services.
You can download a handy E-book created by the Devs over at microsoft that will show you some common enterprise patterns to use for Cross-platform technologies like Xamarin which can be found here
Here's one such example of the kind of patterns those links refer to.
You can also find an overview of various web services that you can use at this link
The options it gives you an overview of are:
ASMX
WCF
REST
So plenty of choice, but depends on your current approach.
If my question isn't clear, please help me improve it with comments.
I'm new to Delphi and dbExpress and I'm just getting acquaintance with TSQLDataset, TDataSetProvider, TClientDataSet and TDataSource classes.
The project that I'm working on uses this components in a way that feels strange to me. There is a huge data module unit that contains lots and lots of the quartet of classes previously described. I'm guessing that there are better (and more modularized) ways of doing this. DataSnap is used only to place this data module in a server application, so the clients access the data through it.
So, let me try to explain some of my doubts:
What is the role of each one of this classes? I read the documentation but I can't get a practical insight on this subject (specially about TDataSetProvider).
Which classes should be in the data module and which should be in my forms?
Is it possible to create an intermediate layer to abstract my business model from my database setup (maybe creating functions that return immutable datasets?)?
If so, is it wise to use DataSnap to do so?
I'm sorry if I'm not clear enough. Thanks in advance.
Components
TDataSource is the bridge between data-aware controls and the dataset (TDataSet descendant) from which they are to get their values.
TClientDataSet is one such dataset. TClientDataSet can be used in isolation, for example to access data contained in xml files, but can also be hooked up to a TDataSetProvider.
TDataSetProvider is the bridge between the in-memory TClientDataSet and the actual dataset that takes its data from a database through some kind of driver. In Client Server development you will usually see a TRemoteDataSetProvider (name may be different, I don't work with these components that often), which bridges the gap between the client and server.
TSQLDataSet is the actual dataset getting its data from some database.
It would feel strange to me to see this quartet all in one executable. I would expect the TSQLDataSet on the server side hooked up to the TRemoteDataSetProvider's counter part. However, I guess that with an embedded database it could be a way to support the briefcase model, which is where TClientDataSet is really helpful (TClientDataset is very powerful, that is just one of its strong points.)
Single datamodule
Ouch. A single huge datamodule is lazy programming or the result of misconceptions about how to use datamodules. It is perfectly normal to have a single datamodule that "hosts" the database connection which is then used by various other datamodules that are more tightly focused on aspects of the application.
Domain abstraction
With regard to abstracting your business model, dbexpress and datasnap should really not be anywhere in your business model. They should be part of your data layer.
TDataSource, TClientDataSet and custom TDataSetProvider descendant(s) can be used to leverage the power of the data-aware controls in the UI while still keeping the UI separate from the business model. In this case the custom TDataSetProvider would be the bridge between the client dataset and the collections and instances in the domain layer.
Even so, I would still expect to see a separate data layer, using TRemoteDataSetProviders or straight TDataSet descendants (like TSQLDataSet) to provide the domain layer with its data.
The single huge data module you mentioned could be part of that data layer, with the client datasets providing the business layer with its data. As you also mention TDataSource as part of a common quartet, the application was probably developed in a RAD-data-aware fashion where UI controls are basically hooked up straight to database columns/tables.
If you want to transform this application to have a more layered architecture, tread carefully and slowly. Get to know the current architecture first and get to know it well enough to see the impact that this kind of transformation would have. The links provided by Serg will certainly help you there. Pawel Glowacki has written extensively about DataSnap.
The project you are working on is a Delphi Multitier Database Application
Your question is too wide for SO and hardly can be answered in its current form - you should learn to understand the underlying architecture.
You can start from video tutorial by Pawel Glowacki:
http://www.youtube.com/watch?v=B4uxLLIUddg
http://cc.embarcadero.com/item/28188
I'm working on an n-tier application that needs a rules engine on the presentation end.
I need to load display rules from a DB into the BLL tier and pass them onto the client. E.g. Item A is outlined in red when propertyX is true, outlined in white when propertyY is true && It should be hidden when neither is true and you do not have the Admin role
The BLL will end up being rules driven at some point, but we will be migrating hard coded logic from the existing client/server app there first.
Looking at WF, it appears to allow me to create and serialise workflows that I can host on the BLL or on the presentation layer.
I expect there to be a large number of rules as different user roles will get slightly different sets of rules for the 50 odd types of entity exposed to the presentation layer.
Is this a good idea?
Would it be simpler to define a DSL and manage everything myself?
There are two things you should know.
First, please bear in mind that Workflow Foundation is optimized for a very long process that runs in background and it's meant to be synchronous, an activity must wait for previous activity to complete.
Although you can do parallel workflow activity in .NET 4, the execution start in a synchronous state. This will add more service layer for your application, because WF will need WCF layer to communicate well, outside its project boundary.
See this workflow foundation overview from MSDN:
Workdlow Foundation overview http://i.msdn.microsoft.com/dynimg/IC102288.gif
Secondly, large rules of workflows will degrade performance in the long run, unless you really NEED long running process such as approval workflow that must wait for correct person with correct priviledge (or positions) to approve. Workflow Foundation is very good at this, especially in .NET version 4 and above.
This is an overview of Workflow Foundation 4:
MSDN Library of .NET 4 Workflow Foundation Overview and you can start from there.
As being used in WPF, you have to call your workflow service asynchronously, otherwise it will block WPF UI thread.
You can further use the new Async API of the next version of .NET 4.0, but this is just a syntactic sugar to ease using always dreaded asynchronous programming.
Therefore I won't recommend Workflow Foundation as a business rule validator. You can simply use the power of data annotations in Entity Framework 4, mapped from your physical database to your business entity layer, then further remodeled to add business logic and rules, and it's much faster.
If you insists, then you'll have to use async code everywhere to achieve complex callback of a workflow in WCF services.
Actually I think that Workflow would be a good fit for this scenario. There are many people who build applications where workflows execute client side and we have good support for this with WorkflowApplication which supports workflows on background threads.
In fact, I wrote the Introduction To State Machine Hands on Lab with this very scenario. In that application a WPF client with the MVVM pattern uses a Workflow in the model to control the behavior of a simulated ATM machine.
I'm curious to get some feedback and ideas on how one could go about building a realtime data streaming application. We can keep the source data generic for this exercise ... throughput info, stock trade pricing, etc. Just something that is constantly changing, and the information is stored in a database.
I am interested in building a silverlight application that the user can pull up and see real-time (or at least, seemingly realtime if polling is the only option) information in a chart or grid as it changes.
As you may imagine, the technology menu for this project is silverlight, asp.net, wcf, and sql server.
What is the right pattern (duplex wcf, polling) for this kind of application?
One example (and please remember, don't limit yourselves to thinking about the financial markets domain) is this "Strategydesk" product from TD ameritrade. You can see how it is constantly updating in real time:
http://www.tdameritrade.com/demo/strategydesk/1497_ameritrade_strategydesk.html
Silverlight has TwoWay DataBinding available to refresh UI seamlessly using ObservableCollections.
On the backend i'll prefer legacy methods "polling" using WCF. Duplex WCP isn;t the right option i think because only one machine can be requester either client or server.
Watch this screen cast:
http://blog.lab49.com/archives/2650
Jason Dolinger has presented a sample SL app for real time Stock updates.. its just a proof of concept.. hope it will help you.
Regards.
You might want to look into using sockets in Silverlight. That will probably be the fastest/most responsive way to send/receive real-time data.
My colleague has found himself in an "interesting" situation. He is working on a Silverlight (2.0) prototype that needs to call existing web services in the enterprise and bind the returned data to data-display controls. The thing is, the web services return .NET DataSets (they are not about to change existing implementations) and Silverlight does not natively support DataSets.
What would a good workaround be? I was thinking an adapter pattern but do not know if middle-man web services to carry out transformations would be a very good idea. Could be tedious if there are many existing web services.
AFAIK, when a .NET web service returns a DataSet, it returns its XML representation (which is pretty friendly). The fact that a .NET client can consume the DataSet directly only abstracts the fact that an Xml Serialization-Deserialization is taking place.
So I would manually query the web services you require, observe the generated XML, and then parse it in the client side.
Another possibility is to take advantage of the fact that Web Services use the standard XML Serializer, so you could create the C# classes from the returned schema and then let the XmlSerializer automatically handle it. I'm not sure if the code generated by the XSD.exe tool will be Silverlight friendly, but it is worth giving it a shot.
Try the following: http://silverlightdataset.net
The dangers and general nastyness of Datasets eh. I would use a generic proxy that is responsible for consuming the webmethod and transforming the dataset into xml/json
Yup, silverlight ds is a great solution, they even have relationships built into it