Flex and ADO.NET Data Services...anyone done it? - apache-flex

Has anyone used ADO.NET Data Services as a data source for Adobe Flex applications? If so, any success stories or tragedies to avoid? If you did use it, how did you handle security?

I use WebORB for .NET to do Flex remoting and then use DLINQ on the server. One tricky thing about using LINQ with WebORB is that WebORB uses Reflection to automatically retrieve all the relationships of the object(s) you return to Flex. This causes severe time penalties as LINQ uses lazy loading to load relationships. To prevent this from happening, I do something like the following:
Override your DataContext's constructor and add the following code:
this.DeferredLoadingEnabled = false;
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Order>(q => q.Payments);
dlo.LoadWith<Order>(q => q.Customer);
this.LoadOptions = dlo;
This tells the DataContext to disable deferred loading of relationships and specifically instructs it to load just the relationships you want, without lazy loading. That way, WebORB isn't causing any lazy loading to happen through Reflection and the number of relationships being transferred to Flex is kept at a minimum.
Hope this helps you in some way. It's definitely one of those little "gotchas" when working with Flex/WebORB and LINQ.

Yes, we use Flex with .Net web services extensively.
Flex can't handle .Net DataSets, or indeed much by way of complex xml types. We found that it was best to keep to relatively simple xml output.
However, if you do that, it can handle .Net web service output fine:
<mx:WebService id="myDataService" showBusyCursor="true">
<mx:operation name="WebMethodName"
resultFormat="object"
result="functionFiredOnComplete();">
</mx:operation>
</mx:WebService>
public function load():void
{
myDataService.loadWSDL( "web method's wsdl" );
myDataService.WebMethodName.send( params );
}
public function functionFiredOnComplete():void
{
// get data
var myData:Object = myDataService.WebMethodName.lastResult;
...

He Asked about ADO.NET Data Services not web service

Flex can only do GET and POST
Flex doesn't understand HTTP Response messages
So in order to have Flex talk to ADO.NET data services you either have to;
1. use a proxy server, but you have to find or build one yourself
2. modify the incoming requests and use $method=MERGE and so on (same as proxy)
3. use another as3 httpService client, there are some opensource initiatives
Then you have to find out how to post data, and it cost a lot of time when you want to create a new record with JSON and specify a Id wich has a link to another table. This because you can't just update the integer, but instead you have to create a link string, it's feels not really easy.
So ofcourse it can be done, but out of the box you really have to make it yourself. I know that Flash Builder 4 will come with a REST import, this could speed up things, but hve no experience for that

Related

How to provide capability like OnActivate (in Autofac) in Mvx.IoCProvider.Register

Autofac provides the OnActivated() method, which provides the capability to run any action after constructing a registered type.
Is possible to use a similar method in MvvmCross? Do you have any ideas to provide the same functionality?
It usually pays to understand the fundamentals of Dependency Injection (DI) instead of relying on particular DI Container features. Ask yourself the question: If I didn't have a DI Container, then how would I solve my problem?
Ironically, it turns out that things are usually much simpler with Pure DI.
If you didn't have a DI Container, then how would you run an action after construction of an object?
The easiest solution is to provide a factory that creates and initialises the object. Assuming the same API and requirements as the Autofac documentation implies, you could do this:
public static Dependency2 CreateDependency2(ITestOutputHelper output, Dependency1 dependency)
{
var d2 = new Dependency2(ITestOutputHelper output, Dependency1 dependency);
d2.Initialize();
return d2;
}
If you still must use another DI Container, most of them enable you to register a factory like the above against the type. I don't know how MvvmCross works, but I'd be surprised if this wasn't possible. If it isn't, you can implement an Adapter over your actual dependency. The Adapter would take care of running the action on the adapted object.
FWIW, if an object isn't in a valid state before you've run some action on it, then encapsulation is broken. The fundamental characteristic of encapsulation is that objects protect their invariants so that they can never be in invalid states. If possible, consider a better API design.

Using ASP.NET Resources in React

I have an old MVC 4 project that uses ASP.NET Resources in Razor views for localization.
I.e in a Razor view you may see
Views/Register.cshtml:
#Resource(() => Local.TermsAndConditions
This will go off and fine
Resources/Register.resx
And find the 'TermsAndConditions' parameter with the correct culture.
Now I don't actually know how all of this works, I've never worked on a multi-lingual application before, but I know that these resx files don't even have the correct information - what actually happens is somehow we fetch these from what looks like a complicated set of SQL tables in the database, using a built ResourceCache class.
I am trying to re-write the front-end using React, but am struggling with how to keep the localization - there are hundreds of entries and I am pulling my hair out a little here.
The only solution I can think of, is to manually find all the keys that would be required to lookup at the top of the view, and send these off to a custom API that will process these values for me, but feel like that may cause a large overhead on my application!
Any ideas?
So I solved this by creating a simple API method
List<string, string> LocaliseStrings (List<string> keys)
{
// get UI culture
// look up translated string
// add to return list in KVP
}
This would be called on every front-end page before anything else, and return the strings necessary

Entity Framework 4.1 and Business Logic Layer

I am trying to use Entity Framework 4.0 for an asp .net application. As of now, it will be old style code behind files and without unit testing but in the future I may use MVP and unit testing but as of now, it is not a concern for me. I am using Database First approach. Here is a model ( I could not post image as I need reputation to post image)
Table: Application (ApplicationID, Name, Hidden)
Table: User (UserID, ApplicationID, Username, IsActive)
Table: Role (RoleID, ApplicationID, Name)
Table: UserRole (UserRoleID, RoleID, UserID)
I have been reading a lot about Entity Framework and how to use it but still could not get a very basic idea about some stuff. Where do I write a code like this for Application, User, Role, UserRole etc?
public List<Application> GetAllUnhiddenApplications()
{
List<Application> applist = null;
using (CustomAppsPortalEntities ctx = new CustomAppsPortalEntities())
{
applist = (from app in ctx.Applications
where app.Hidden == false
orderby app.Name
select app).ToList();
}
return applist;
}
I have separated Context and Entities in separate projects Project.Data and Project.Entities respectively. My question is if above code belongs to BLL (class name ApplicationBLL) or DLL (ApplicationDLL)? From past 2 days, I have been searching lots of SO questions, blogs, tutorials and different people have different approach. Here is my dilemma.
If I put the code in Data layer, then in the business layer, I have to create a "pass through" function like ApplicationBLL.GetAllUnhiddenApplications which will return ApplidationDLL.GetAllUnhiddenApplications. I have to repeat it for all the queries and basically whole BLL will eventually become "pass through" layer for DLL. Can you give me a concrete example of what Business layer will be used for in reference to above schema?
If I put the code in Business layer, then linq will exist in Business layer which eventually will be converted to SQL by Entity Framework so it is like exposing query logic to Business Layer.
Our Environment
Our environment is fast paced and want to complete this project as soon as possible with the moderately proper approach where there is a separate layer but in the future when we find time, we may refactor the code and make it really robust but it is not a concern as of now but if the time permits, we want to implement best practices right now versus refactoring code in the future.
The above code would typically be in the BL layer. Using linq in your BL layer is fine because your linq queries are still data persistence ignorant. From linq queries perspective, it's querying objects from entity framework.
What you might be missing is a "repository pattern" and "unit of work patter". The repository pattern acts as an interface to entity framework. It allows you to interact with EF objects like in-memory collections. Typically I keep all repositories in one project and reference accordingly. To give you an example, Microsoft Spain provides a n-tierd example,
http://microsoftnlayerapp.codeplex.com/
It's very over engineered, but I believe it will give you what your looking for.
Many people argue that EF IS the DLL.
Typically, I set my projects up something like this...
D ---> Presentation Layers (MVC, WCF, WinForms, etc)
A |
T V
A ---> Business Logic Layer
|
M V
O ---> Entity Layer / DLL
D
E
L
The Data Models project is really just a collection of POCO's that can be used in any of the other projects.
The Entity Layer is your EDMX file and Context.
It should be fine to access the context in the Entity/DLL layer, since .Net has abstracted everything out for you.
If you think about it, the whole reason to abstract out a DLL layer is so that you can change databases without having to change the BLL. With EF, you can change a database in 1 step and everything should still work.... as long as your schema stays the same.

JSON + SOAP - Is DataContract necessary?

Here's my problem.
I'm using SOAP to retrieve information from a third-party web service.
Response time is too high, so I was planning on using JSON instead, at least in a couple of methods.
For this I'm using DataContractJsonSerializer, but I seem to be having some trouble.
For example, in SOAP there's a method called getAvailablePublic with returns an object of type getAvailablePublicResponse.
There's an equivalent for this method in JSON, which also returns a an object of type getAvailablePublicResponse.
In order to deserialize the information I needed to create a couple of data contracts, and here are my concerns:
Do I really need to create a DataContract? Why can't I use getAvailablePublicResponse object from asmx?
The problem is that if I create a DataContract, I need to use a different name other than getAvailablePublicResponse, as I would have two objects with the same name (the one created by me, and the one from SOAP), and this would require making several changes in my solution.
Hope this makes sense.
Thanks.
Can you post your client code that is making the call to the web service? I don't know what you are using now, but I'm a fan of RestSharp for making remote calls and serializing JSON to C# classes. Something like this:
RestClient client = new RestClient("http://some.domain.com/someservice?someparam=yes");
var results = client.Execute<MyGreatDTOClass>(new RestRequest(Method.GET));

Is there any way to use XmlSiteMapProvider within WinForm/Console/VSTest application?

I wonder whether there is a workaround for using the standard XmlSiteMapProvider within a non asp.net application, like WinForm/Console or, in my case, VS Unit Test one.
The following code fails, because it cannot create a path to the .sitemap file inside a private GetConfigDocument method.
XmlSiteMapProvider provider = new XmlSiteMapProvider();
NameValueCollection providerAttributes = new NameValueCollection();
providerAttributes.Add("siteMapFile", "Web.sitemap");
provider.Initialize("XmlSiteMapReader", providerAttributes);
provider.BuildSiteMap();
I feel the right solution is to write another provider.
I do not see why not. It is just a provider that implements an interface. You may not need many of the features, but you can access the API for what it provides you. Your WinForms screens can simply use the Urls for identification so that you can determine your place in the hierarchy.
What you may have to do is create a custom implementation of the provider because it will use the HttpContext to get the Url of the current web request to identify current placement while you will need to get that value differently. That is what could be tricky because your WinForm application could be displaying multiple windows at time. If you know there is only one window showing at a time you could use a static value which is set prior to accessing the SiteMap API.
Now you have to question the value of using an API if you have to do all of the work. There may not be enough benefit to make it worthwhile.

Resources