哪种数据访问方式更适合silverlight 4?
2010-03-17 15:06
267 查看
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
Web Services: Interface-based Data Access
ADO.NET Data Services: LINQ-based Data Access with change management
RIA Services: Interface-based Data Access with change management
Let's dive deeper into explaining these differences and why that might matter.
Reasons to Use: Any existing investment in web services can be a great reason to use them (whether in code or skillset). Also, web services are often used in cases where a project wants a very close control over the flow from the application to the database.
Reasons to Avoid: With web services you end up having to keep track of the changes yourself and know what services to call with updates. Any need for batching or transactional support gets cumbersome and code-intensive.
Underneath its covers it takes this URI based API and converts it into a LINQ call for GETs and to API calls to the provider for inserts, updates and deletes. That means that ADO.NET is a thin layer who's purpose is to translate the URI model to data access code. But its better than that...
The real power of ADO.NET Data Services for Silverlight is the inclusion of the Client Library. This client library allows you to issue LINQ queries defined in the client and executed on the server. While the LINQ syntax is somewhat limited when compared to the server, it fulfills the 80% case and ADO.NET Data Services allows you to add operations to fill in the rest when necessary. In addition, the client library includes a powerful data context class that can monitor changes and issue changes in batches with transactional support.
Exposing your data access with ADO.NET Data Services is about exposing queryable end-points instead of defining an interface. This is what makes is unique. For example, we can query our service using a LINQ Query like so:
Reasons to Use: Want a simple, secure model where the developers can define the queries they need in code instead of changing the interface as the needs change. The ADO.NET Data Services' client library makes the amount of code you write on the client small as it becomes LINQ calls and working with the context class.
Reasons to Avoid: When you want tight control over the interface to your data access and do not want developers issuing LINQ queries directly from the client code.
Because RIA Services is based on a server-side query defined in its interface, on the client we call the query by calling the call on the interface:
While in ADO.NET Data Services you are issuing LINQ queries, RIA Services also allow you to add LINQ constraints to the query endpoints. For example instead of just creating a query by calling the interface, you can add LINQ expressions to the endpoint like so:
Reasons to Use: RIA Services is a good choice if you expect to develop a straightforward application minimum number of tiers. It works best in Rapid Application development scenarios versus large architected applications. RIA Services does support a mix between the interface based from Web Servics and and LINQ based querying that is supported by ADO.NET Data Services.
Reasons to Avoid: RIA Services leverages a lot of magic code generation to make it work and that is harder to debug than it should be. Integration with large enterprises is possible, its not as easy it as it should be.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
Web Services: Interface-based Data Access
ADO.NET Data Services: LINQ-based Data Access with change management
RIA Services: Interface-based Data Access with change management
Let's dive deeper into explaining these differences and why that might matter.
Web Services
Using web services is the tried and true method for communicating across the firewall. This pattern is well known and reliable. In general this requires you specify an interface for the CRUD operations as separate operations on a web service then dutifully call them in your Silverlight code.Reasons to Use: Any existing investment in web services can be a great reason to use them (whether in code or skillset). Also, web services are often used in cases where a project wants a very close control over the flow from the application to the database.
Reasons to Avoid: With web services you end up having to keep track of the changes yourself and know what services to call with updates. Any need for batching or transactional support gets cumbersome and code-intensive.
ADO.NET Data Services
ADO.NET Data Services is a simple REST-based facility for data access. It relies on the HTTP stack to help define the interface. GET calls become Reads, POST becomes Updates and so on. It uses ATOM or JSON for its serialization format so it is consumable by a variety of clients.Underneath its covers it takes this URI based API and converts it into a LINQ call for GETs and to API calls to the provider for inserts, updates and deletes. That means that ADO.NET is a thin layer who's purpose is to translate the URI model to data access code. But its better than that...
The real power of ADO.NET Data Services for Silverlight is the inclusion of the Client Library. This client library allows you to issue LINQ queries defined in the client and executed on the server. While the LINQ syntax is somewhat limited when compared to the server, it fulfills the 80% case and ADO.NET Data Services allows you to add operations to fill in the rest when necessary. In addition, the client library includes a powerful data context class that can monitor changes and issue changes in batches with transactional support.
Exposing your data access with ADO.NET Data Services is about exposing queryable end-points instead of defining an interface. This is what makes is unique. For example, we can query our service using a LINQ Query like so:
// Silverlight Code // Create the query using LINQ var qry = (from g in ds.Games where g.Price < 50m orderby g.Name select g) as DataServiceQuery<Game>; // Execute the Query // (This part is getting cleaner in ADO.NET Data Services v1.5) qry.BeginExecute(new AsyncCallback(r => { games2.ItemsSource = qry.EndExecute(r).ToList(); games2.DisplayMemberPath = "Name"; }), null);
Reasons to Use: Want a simple, secure model where the developers can define the queries they need in code instead of changing the interface as the needs change. The ADO.NET Data Services' client library makes the amount of code you write on the client small as it becomes LINQ calls and working with the context class.
Reasons to Avoid: When you want tight control over the interface to your data access and do not want developers issuing LINQ queries directly from the client code.
RIA Services
As the new kid on the block, RIA Services has a lot to offer. RIA Services is based on the idea of creating a data access API on the server and at the same time creating the client code in Silverlight (and other platforms in the future). Its focused on sharing code between the client and the server including validation logic. In addition, while it allows you to create a set interface, it also provides a context object which can monitor changes on the client and batch those changes back to the server. In some ways RIA Services is like a hybrid of Web Services and ADO.NET Data Services.Because RIA Services is based on a server-side query defined in its interface, on the client we call the query by calling the call on the interface:
// Silverlight Code // The context object that tracks changes XBoxGamesContext ctx = new XBoxGamesContext(); // Our RIA Query, really a call to an interface var qry = ctx.GetGamesByGenreQuery("Shooter"); // Bind the data theList.ItemsSource = ctx.Load<Game>(qry).AllEntities;
While in ADO.NET Data Services you are issuing LINQ queries, RIA Services also allow you to add LINQ constraints to the query endpoints. For example instead of just creating a query by calling the interface, you can add LINQ expressions to the endpoint like so:
var riaQry = ctx.GetGamesQuery() .Where(g => g.Price < 50m) .OrderBy(g => g.Name); LoadOperation<Game> op = ctx.Load<Game>(riaQry);
Reasons to Use: RIA Services is a good choice if you expect to develop a straightforward application minimum number of tiers. It works best in Rapid Application development scenarios versus large architected applications. RIA Services does support a mix between the interface based from Web Servics and and LINQ based querying that is supported by ADO.NET Data Services.
Reasons to Avoid: RIA Services leverages a lot of magic code generation to make it work and that is harder to debug than it should be. Integration with large enterprises is possible, its not as easy it as it should be.
"So Which Would You Suggest?"
While I paint this picture of data access in Silverlight with a broad brush, I still get the question to suggest one over the other. The fact remains that there isn't a right/wrong answer here. A lot of it depends on the environment, project and skillset of the developers. So, no...I won't tell you what I suggest because I don't know the requirements and environment you work in. That's why they pay you the big bucks to be a developer, right?相关文章推荐
- 授权用户访问数据字典三种方式
- spring mvc 的jpa JpaRepository数据层 访问方式汇总
- 采用指针访问方式从键盘给数组a[N]输入数据,然后对元素值重新按逆序存放并输出
- 多个线程访问共享对象和数据的方式
- spring mvc 的jpa JpaRepository数据层 访问方式汇总
- Android数据存储和访问之SharedPreferences存储方式_用户登录记住密码案例
- 多线程要访问共享数据的方式
- 多线程访问共享对象和数据的方式
- Android学习 —— 数据的存储与访问方式一: 文件存取
- spring mvc 的jpa JpaRepository数据层 访问方式汇总
- 执行计划-数据访问方式(全表扫描与4种索引的方式)
- 以对象的方式来访问xml数据表(一)
- Beginning Silverlight 4 in C#-数据访问和网络
- httppost方式访问网络数据
- 网络、磁盘、内存哪种方式更适合保存数据?
- Android学习 —— 数据的存储与访问方式三: SQLite数据库
- 稳扎稳打Silverlight(20) - 2.0通信之WebClient, 以字符串的形式上传/下载数据, 以流的方式上传/下载数据
- LinkServer--访问远程数据表三种方式
- WP7访问云端数据的方式
- Silverlight调用WebService时出现的跨域方式访问服务