Hi Rocky,
I feel completely lost like those guys in the Oceanic 815.
Reading Using Csla 4 - Data Access ebook p. 50, I get this A) implementation of DataPortal_Fetch:
#if SILVERLIGHT [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)] public void DataPortal_Fetch(int id, Csla.DataPortalClient.LocalProxy<ProjectEdit>.CompletedHandler handler) { try { // invoke external DAL here (encapsulated invoke) handler(this, null); } catch (Exception ex) { handler(null, ex); } } #endif
What I can find in every single project is this other B) implementation:
#if !SILVERLIGHT private void DataPortal_Fetch(int id) { // invoke external DAL here (encapsulated invoke) } #endif
like this one found on PTracker's ProjectEdit
#if !SILVERLIGHT private void DataPortal_Fetch(int id) { using (var ctx = ProjectTracker.Dal.DalFactory.GetManager()) { var dal = ctx.GetProvider<ProjectTracker.Dal.IProjectDal>(); var data = dal.Fetch(id); using (BypassPropertyChecks) { Id = data.Id; Name = data.Name; Description = data.Description; Started = data.Started; Ended = data.Ended; TimeStamp = data.LastChanged; Resources = DataPortal.FetchChild<ProjectResources>(id); } } } #endif
aaa
I find the B) implementation simple to understand. This code won't build on the Silverlight client side library as this library has a SILVERLIGHT conditional compilation symbol. This means this method won't exist on the Silverlight library. When the Silverlight client side factory method runs, it invokes the server side DataPortal_Fetch method that is reproduced above as implementation B).
I also understand that in order to invoke the Silverlight client side DataPortal_Create method (aka RunLocal), the method must be implemented and must exist in the client side Silverlight library. For this to happen, this method must accept a callback parameter for consistency. When the implementation isn't local, all remote DataPortal call must use a callback parameter (CompleteHandler) and the purpose is to keep the same parameters/signature no matter where the code runs, client side or server side.
If all projects I saw use the implementation B), Csla must be doing some hard job like:
Back to the point, there are four questions:
Regards
This is all architectural, and has somewhat to do with the scope of the Data Access ebook.
There is no data access on Silverlight. No ADO.NET, nothing really. Just isolated storage stream access to the file system (in limited ways).
The ability to implement "data access" methods on the Silverlight client exists primarily to support calling remote services manually. This type of application is a 1-tier Silverlight app, sometimes called an "edge application" because it runs on the edge of a larger service-oriented system.
I chose to focus the Data Access ebook on the more common scenario, where the application really does data access - which means the data access code is running on the server in .NET. The server, of course, does have things like ADO.NET.
If you use the data portal to allow the client to interact with the application server (the normal case), then you get the patterns shown in the Data Access ebook.
In the final book in the series, the WP7 book, I'll focus almost entirely on edge applications. The most common scenario (I think) for mobile apps is to build an edge application. The reason is because a service-oriented architecture provides better decoupling between the mobile app and the server. That is important because it is easier to version the server than the mobile app - you really can't force end users to update the app on the phone, so you have to assume the "client" and server will get out of sync.
Thanks for your answer Rocky. It's a very important clarification.
In fact, on p. 5 you show a very simple sample that I agree is the most common scenario.
public static void GetPersonEdit(int id, EventHandler<DataPortalResult<PersonEdit>> callback) { DataPortal.BeginFetch<PersonEdit>(id, callback); } #if !SILVERLIGHT public static PersonEdit GetPersonEdit(int id) { return DataPortal.Fetch<PersonEdit>(id); } private void DataPortal_Fetch(int id) { // invoke external DAL here (encapsulated invoke) // or implement DAL code here (encapsulated implementation) }
This sample is completely different from the A) implementation of p. 50 that is showing the edge application scenario:
I chose to focus the Data Access ebook on the more common scenario, where the application really does data access - which means the data access code is running on the server in .NET. The server, of course, does have things like ADO.NET.
If you use the data portal to allow the client to interact with the application server (the normal case), then you get the patterns shown in the Data Access ebook.
I agree this is the most common scenario but, from a statistical point of view, I can't agree with the bit "the patterns shown in the Data Access ebook". On the Encapsulation Models chapter there are 6 samples showing the edge application scenario that are introduced by the phrase "here’s an example of a Silverlight implementation". So the big picture we get is the edge application implementation.
Edge applications are refered only the Overview ebook. May I suggest that the "edge application versus most common scenario" clarification be included in the Data Access ebook? Before writing this post, I looked for some explanation both in Objects and Data Access ebooks and found none. I guess this would save other people a few hours of ebook and forum browsing. Note that a simple change like"here’s an example of a Silverlight edge application implementation" whould make a big difference...
I'll add this as errata (errata@lhotka.net) to address one way or another. At the very least it is clear that my discussion of the topic can be misleading.
Thanks Rocky.
Copyright (c) Marimer LLC