Rants Tagged with “ADO.NET”
1 2 3 4 5 6 7 > >> (Total Pages: 7/Total Results: 63)
UPDATE: This may be incorrect. I am working with Microsoft to understand if I got this wrong. I'll update this blog once I get the story right.
As everyone has announced already, Visual Studio 2008 and .NET 3.5 have released an SP1 that includes a bunch of fixes as well as the Entity Framework as well as ADO.NET Data Services. To support this, the Silverlight team dropped a new version of the Visual Studio tools that work with Silverlight 2 Beta 2 and Visual Studio 2008 SP1.
The one caveat is that the Silverlight library for ADO.NET Data Services is not compatible with the RTM of .NET 3.5 SP1's version of ADO.NET Data Services. Since its not compatible, if you are using ADO.NET Data Services with Silverlight, you should wait to upgrade to Visual Studio/.NET SP1 until Silverlight 2 is released (there aren't any release dates for this yet).
Note, that this is a little confused by the fact that SQL Server 2008 (released last week) requires Visual Studio 2008 SP1 RTM to install, so if you need both Silverlight 2 Beta 2 to work with ADO.NET Data Services and SQL Server 2008, there is no good solution for getting all three installed at once.
To many developers this may seem odd. I talk with many staunch ALT.NET guys, and the DDD philosophy seems to be that data is a top-down or at worse, bottom up design problem. The issue here is that there is an assumption that just simply not true that data design is part of most software development projects. The reality based on my experience as well as the experience of talking with developers in the community is that many projects (though its hard to exactly quantify what percentage) begin with existing data. This is especially true in the enterprise where data exists in many forms from new databases, legacy servers (e.g. mainframes) or even flat files and XML. It is the rare project that is new code against all new data.
For new projects, creating a new database schema that at least in some part mimics the design of a project makes sense. The problem is that over time the data must evolve. I think the reality is that depending on the organization this can be very different. There are some opinions that I think impact the maturation of a data model:
- "Well if they want access to the data outside the application, I will expose that as a service interface." - I think this is coming from the world of a consultant not a enterprise developer. The reality is that the data maturation happens over time with the help of DBAs, developers and IT people. Its a complicated situation and isolating the database to the non-development stake holders is something that just doesn't happen in the long run.
- "Transactional schemas are not a good solution for reporting." - While I don't disagree with this idea, it doesn't happen in the real work either. In most large organizations, they have need for data coming out of systems and cannot wait for data warehouses, data marts or reporting servers to be created and maintained. If they are created as part of the application development, they usually get the short straw of maintenance. Reporting happens against transactional schemas...period...get over it.
- "If the application is designed right, the DBA should never need to get involved...we can solve perf problems with caching and smarter data access." - This assumes that the data is isolated from the rest of the organization. This doesn't happen either. In addition, data changes over time and that's where DBA's can be exceptionally helpful. In my opinion, the form of the data can be improved over time as real data is used in a system. What works for a 1GB database rarely works for a 1 TB database. Lastly, there are often many more readers of data than you might expect. This is related to the reporting story, but also ad hoc attaching of data (damn you Excel and Access) happens. You can't control the gateway to the data as the guys that sign the checks sometimes make dumb decisions that impact the organization...that won't change.
Now I am not suggesting that we need to dumb down designs to deal with the nature of data, but understand that the IT infrastructure of deployed products is a lot more fluid than developers would like. For me it is, "Hope for the best and plan for the worst." This means understand that pushing a design philosophy that can help developers get their job done in a more efficient way as well as create better software is what we all are trying to do, but there are no black and white lines drawn here. No *rule* applies in all situations. I laud the ALT.NET guys for trying to inject better skills and tools into the process, I just rail against the ferocity of zealotry that comes in some of the message. When enterprise developers hear this, they just tune it out instead of taking what helps them and leaving the rest.
That's just my opinion...
The Entity Framework "No Confidence Vote" is a couple of days old now. I wanted to give the Internet a couple of days to chew it over and figure out where it really fit into the big picture. If you follow me on Twitter you may have seen some back and forth between Scott Belware and I recently. Most of this back and forth has been about his attacks of the Microsoft community (attacks of the technology or even the company are fair game as far as I am concerned). Getting personal by accusing me, the Microsoft community or even individual EF Team member's directly seems petty and unnecessary.
In that same light, some of the ALT.NET community (I won't name names) have accused me of being a shill for Microsoft's techologies. Anyone who has ever seen me talk about any Microsoft technology already knows that I pride myself in my centrist view of any technology (Microsoft's or others).
For me the power of the Entity Framework is *not* in its use as a ORM. There are dozens if not hundreds of ORMs out there. Depending on your specific use case, some are great...some are less than great. None is a perfect ORM for every case. My attitude about the Entity Framework is that it isn't a great ORM...but that it isn't trying to be. The power of the Entity Framework is in a common language for communicating a model. The Entity Data Model can handle complex scenarios. The big advantage in using the Entity Framework comes when the Entity Data Model is used by Microsoft and external projects. The effort required in building a real model of existing enterprise data is not trivial. The labor involved can only be recouped if the model is useful in other scenarios as a model of your data throughout your organization. That's not the case yet. Microsoft isn't there. In addition, the Entity Framework is not a good tool for the top-down development that Domain Driven Design and Model Driven Design are espousing. Again, I don't think that was ever their intention. But its important to know. There are other criticisms of the technology to me made but that's not the purpose of this post. Instead its to say that its a great start on a long-term strategy and for many people now isn't yet the time to use the Entity Framework.
But that being said, what is my opinion the No Confidence Vote? I don't think the technology should be killed. I think its a great start but still flawed as many v1 technologies are. My chief complaint with the whole movement in trying to kill the Entity Framework is the tone of the message. Angry bitter attacks on Microsoft and the Microsoft community do not help create dialog. It just creates division and a dug-in mentality. My experience is that if you attack a side, they are unlikely to change their minds but instead will just becoming more resistence to listening. Maybe that's the point. If you create an environment where Microsoft fails, then maybe nHibernate will get more traction.
So what do I think of nHibernate specifically (as it is the elephant in the living room that no one wants to mention)? Its a great framework. Period. I use it and have used and recommended it with past clients. I will continue to recommend it (and actually recommended it as well as other ORM's in a recent user group talk in defference to the Entity Framework in the v1 timeframe). So why do I care about the Entity Framework if I like nHibernate? Because they meet different goals. nHibernate is a persistence framework (or a ORM if you prefer). But it doesn't attempt or do a very good job of sharing its model across non-code environments (reporting, BI, etc.) And it shouldn't. Its not its job.
If I had one complaint with nHibernate it is in the realm of tooling. CodeSmith and MyGeneration templates are fine but they typically only do a object-to-table mapping. Everything else requries that you hand-code the XML. I think nHibernate design tools is where much of the effort for the project should be focused. That's why so many Microsoft developers have latched onto LINQ for SQL and Entity Framework. Its confortable for them to build models visually.
One last note, of the personal attacks I wanted to point out one person who is taking way too much shrapnel: Julia Lerman. I've known Julia for a number of years and I think she is exceptionally talented and very well intentioned. Picking on her because of her visibility in the Entity Framework is shameful. I have never known her to not talk about the warts as well as the benefits and I expect her forthcoming book will do the same. The real shame of this personal attack is that after many years in the community, she has taken on her first book. Writing your first book is a particularly vulnerable time for anyone. Having to weather the hostility towards the Entity Framework when she is just writing about the technology, not taking ownership in its authorship is a tough thing to do. I expect she'll come out the other side fine but it doesn't seem fair to deal with both at the same time.
When I deployed the small test application (http://www.silverlightdata.com/simple), it was pretty apparent that it was performing really badly. Some of this is because my ISP upload speed isn't great but it was still taking far too long I thought. This was a simple app with not much data, so I knew I wanted to find out what was happening. If you haven't seen the site, its basically an editor for the Product table in the Northwind database. Nothing special really.
ADO.NET Data Services does a lot of work for you under the covers. This is good because we're not being asked to write a lot of serialization and transportation code, but it can be bad because it becomes more difficult to see why things are happening. Fiddler2 to the rescue!
If you're not familiar with Fiddler2, its basically a great tool for watching web traffic so you can see what is actually happening over the wire. For ADO.NET Data Services, we want to see the actual communication over the wire to see what was being sent to and from the Silverlight application. First, grab the Fiddler2 tool (http://fiddler2.com/) and come with me!
So I fire up Fiddler2 and run the example page. What do I see? Nothing. None of the traffic is showing up. A quick Google search reveals that Fiddler doesn't work on localhost or 127.0.0.1 (kinda the same thing). I found an odd workaround...add a period after the IP address. So my "http://localhost:8000/Default.aspx" test page became "http://127.0.0.1.:8000/Default.aspx". The period after the "1" is not a mistake. Once I did that, the requests were showing up in Fiddler2. Wahoo!
So what did I see? Here's a look at the Fiddler2 window (You can click it for a bigger view):
Looking at the request to Products.svc, I picked the "TextView" tab to see the actual body of the message. Looking at it I noticed this Picture property that was base-64 encoded. Uh oh...I didn't even notice that we are getting pictures...in fact we're getting duplicate data. My LINQ request was:
var qry = from p in TheContext.Products.Expand("Supplier")
.Expand("Category")
orderby p.ProductName
select p;
I knew that I would be getting duplicate data by using the Expand extension method. Expand says to embed the related entity (the Supplier and the Category) so that our object model doesn't have to lazy load them. Of course I wasn't paying attention. The Category has a picture stored in the database. I am not even using it (and couldn't since the image is a GIF and Silverlight can't display GIFs) so retrieving it is pretty useless. Here's a quick view of the underlying Entity model:
The fix for me was to simply remove it from the model, but I am looking at different ways of really solving it including delving into how the "select" statement might filter these out, though I expect that doing three queries (one for Products then just returning Suppliers and Categories to remove the duplicate data would be much more efficient yet.
One caveat, this is the first release of the ADO.NET Data Services' Silverlight Client Library so give it time to improve some of the performance issues. But like other data access libraries, sometimes small changes can make large improvements in performance.
Hope this helps you debug your own ADO.NET Data Services projects.
UPDATE: I had the PUT/POST reversed. It reads correctly now. (Thanks to commenter Rob for pointing it out).
Now that Silverlight 2 Beta 2 has launched, we have the ability to consume ADO.NET Data Services (formerly Astoria) from within Silverlight projects. ADO.NET Data Services are a perfect match for client-side technologies like Silverlight and ASP.NET AJAX.
For the uninitiated, ADO.NET Data Services is a new part of the .NET 3.5 framework that supports exposing a data model (e.g. LINQ for SQL, Entity Framework, etc.) as a set of queryable REST endpoints. ADO.NET Data Services maps the four data verbs into the four HTTP verbs:
- Create == POST
- Read == GET
- Update == PUT
- Delete == DELETE
Essentially it provides a way to use a data model across the firewall. It works by exposing IQueryable endpoints through a URI-based syntax allowing developers control over how the data is retrieved through:
- Filtering
- Sorting
- Paging
- Shaping
In addition ADO.NET Data Services utilizes JSON and Atom (though Plain Old XML may be supported eventually) as the serialization formats. These make it easy to consume in client-side interfaces like Silverlight and AJAX. For more information on ADO.NET Data Services, see there site:
http://msdn.microsoft.com/en-us/data/bb931106.aspx
Before you can consume a Data Service in Silverlight, you will need to create a model and service. See Guy Burstein's walkthrough of creating the service here:
http://blogs.microsoft.co.il/blogs/bursteg/archive/2008/05/12/visual-studio-2008-sp1-ado-net-data-service-walkthrough.aspx
You *can* use LINQ to SQL as your data model but currently it does not have support for updating via ADO.NET Data Services so if you need to read and write data, you should start with an Entity Framework data model.
In Silverlight 2 Beta 2, ADO.NET Data Services is composed of an in-memory library allows asynchronous LINQ queries that are translated into the URI syntax automatically. Before you can get started you will need a a client-side version of the Data Context object and data contract classes for the entities in your data model. To do this, simply use the DataSvcUtil.exe tool located in the C:\Windows\Microsoft.NET\Framework\v3.5\ directory. Typically you would call it by specifying the URI of the service, the name of the class file to create and what language to use:
DataSvcUtil.exe /uri:http://localhost:8888/YourService.svc
/out:dataclass.cs
/language:CSharp
Once that class is created, add it to your Silverlight project. You will also need to add a reference to the System.Data.Client.Services.dll assembly. Now we are ready to get some data.
First we need to create an instance of the context class. This class exposes each of the model types as queryable properties. When creating an instance of the class, you must specify a URI to the service itself:
NorthwindEntities ctx =
new NorthwindEntities(new Uri("/Products.svc", UriKind.Relative));
Querying data with Data Services looks much like any other LINQ-based query:
var qry = from p in ctx.Products
orderby p.ProductName
select p;
Normally, you could execute the query directly by calling something like ToList() against the query. Since that operation would cause a synchronous web request to happen across the network, that isn't supported in Silverlight 2 Beta 2. In fact, if you try you will simply get a NotImplemented exception. In order to execute these queries, you will need to cast the query into a DataServiceQuery. The DataServiceQuery allows you to call BeginExecute to start an asynchronous query as seen below:
// Cast the query to a DataServiceQuery
DataServiceQuery<Product> productQuery =
(DataServiceQuery<Product>)qry;
// Start the execution
productQuery.BeginExecute(new AsyncCallback(OnLoadComplete),
productQuery);
Once the query completes, it will call the OnLoadComplete method that was specified in the AsyncCallback. In this method, you first grab the DataServiceQuery that you sent with the request then end the execution to retrieve the results as seen below:
void OnLoadComplete(IAsyncResult result)
{
// Get a reference to the Query
DataServiceQuery<Product> productQuery =
(DataServiceQuery<Product>)result.AsyncState;
// Get ther esults and add them to the collection
List<Product> products = productQuery.EndExecute(result).ToList();
}
While its not as straightforward as synchronous execution, the new ADO.NET Data Services certainly works well in Silverlight 2 Beta 2 and provides a great way to use existing or planned data models over Internet applications. There are a couple of caveats:
- Error handling and communication is very confusing right now as most real errors are being swallowed by the server instead of communicating back to the client. To find out what is really happening, use of Fiddler and enabling breaking on the throwing of all .NET exceptions will help a lot.
- There are bugs on updating data that may get in your way. Using Batch Saves will solve most of these issues.
- Currently the Data Contract objects do not support INotifyPropertyChanged or INotifyCollectionChanged so data binding may be affected in some cases.There are partial methods for detecting changes to specific properties which makes implementing the INotifyPropertyChanged interface trivial, but not quick. Future versions (e.g. post-RTM) will give us better control over the generation of the data contract classes.
- There is no built-in Visual Studio support to build the data contract/context classes. This is also coming soon, though the exact schedule is unknown.
I am currently working on two examples for this (a simple one and a more complex one) as well as an article for MSDN, all of which will greatly expand the details of how to use ADO.NET Data Services (including how to save changes back to the server. Be sure to watch here for details of those samples and articles.
There is a bug in the current ADO.NET Data Services that ships with .NET 3.5 SP1 Beta 1. The problem involves saving related data. If the child object requires the relationship to the parent object, the update fails.
For example, if you have a Customer with a list of Orders. The relationship between the Customers and Orders is 1...* (0 or 1...* doesn't cause this bug). If you create a Customer and an Order to be updated with the ADO.NET Data Services client library at the same time, the current code attempts to save both the Customer and Order and then update the link between them separately. Of course if the relationship really is 1...*, then you can't save an Order that doesn't have a customer so the update fails. Unfortunately this can update the Customer and just ignore the error with the Order not saving.
The only way to make this work is to relax the relationship so you can create the unrelated child object.
This is a bug in the server code and will be fixed in future builds of ADO.NET Data Services.
HTH
I've known Julie Lerman (or is it Julia these days ;) for a long time now. She's an excellent resource for everything data related. In particular she's been keeping up with the Entity Framework and ADO.NET Data Services (formerly Astoria) updates in .NET 3.5 and VS SP1 Beta that was just released this week. If you are upgrading projects (like I am), she has two excellent blog posts about how to upgrade your projects:
New Entity Framework Changes
New ADO.NET Data Services (Astoria) Changes
If you havent voted, please feel free to vote for what data access strategy here:
http://wildermuth.com/2008/03/21/Data_Access_Strategies.aspx
For those who were interested in the results:
One thing that I took away from this is that some strategies did not get any votes (and I expected them to) like CSLA. I think that's a product more of the fact that Rocky's readers probably don't read my blog...so the poll is very unscientific. I was surprised by the sheer number of LINQ for SQL respondents and the big Entity Framework numbers. Both being new technologies, I didn't expect there to be much usage yet. Go figure.
I had interesting conversations with a number of people about different data access/ORM strategies at MIX recently and was trying to understand where people are spending their efforts in consuming data. The conversation was essentially a discussion of who is using what to access data in .NET applications. I had assumed that certain solutions were widely used and others were not but I didn't have a good idea of what the market was really like. To help me with this I am asking you (my readers) to share with me where you are investing time in data access by taking the following poll:
I will be at the Alabama Code Camp this weekend to talk about Silverlight, the Entity Framework and Astoria. The talks I am doing are:
Feel free to stop by and harrass me with questions or disagreements. I'll be there all day.
