I am developing a Flex / Flash application which talks to an ASP.Net / C# backend. Is there any way I can share code between the two?
The server provides a reasonably interesting domain model which the client is designed to maniuplate. Ideally I would like to be able to define this domain model once and have both sides use it for consistency. I am after all the benefits that come with being DRY.
I'm new to Flex but the sort of thing I had in mind was some intermediate language that compile to both C# and ActionScript.
Update
I currently have a basic REST style web service which sends XML serialized versions of the objects down the wire to Flex. This works fine but what I am really interested in is being able to share simple business logic that goes along with these objects. There are certain business rules that need to be processed on both the server and the client and is possible I would prefer not to have to call back to the server for performance reasons.
I faced this problem as well, so I wrote a C# to ActionScript converter.
http://cs2as.codeplex.com/
Write your logic in C#, and add this utility as a post-build step. Then your business logic will be available in both environments. It works very well for me - I'm using it to share over 30,000 lines of code.
I'd hack together a domain model specification and have it generate models in both languages. But that's probably not the most time-effective thing to do.
Check out http://www.fluorinefx.com/ (It is open source flash remoting). I have used it extensively to call web services written in C# from ActionScript, and it works great. Once nice thing is that your c# can return a DataSet (or something similar) and the Flourine framework will convert that into an object ActionScript understands.
Not that I'm aware of, C# is essentially a strongly-typed, compiled language and ActionScript is a loosely-typed, interpreted language. Chalk and cheese I'm afraid.
What if you serialize the objects to XML and send them to Flex....that would at least let you share the data
Update
You can pass objects through the use of Lists, but what you're really passing through is just the data.
You can't really pass a 'method' to a client.
They don't necessarily have to honor it. Once they're in possession of the data, you can't control whether they honor the methods you passed or not.
You wouldn't want to trust anything they send back to you subsequently.
I think the issue is with the set-up.
You can process anything you want on the client side using ActionScript, and you'll just have to put the business logic you want to manipulate in the ActionScript side of things if you want to do it on the client-side.
Olde Answer
I use Flex and C# together through the use of a web service layer.
You may want to look at creating web services to have flex talk to your C# code.
Web Services with ASP.NET
CodePlex ASP.NET Tutorial (web services)
try weborb # http://www.themidnightcoders.com/products/weborb-for-net/overview.html
Related
There is a need to have a calculator for our invoices which will be used both in the web UI and in the back-end. This requires two implementations of the same logic in Javascript and C# and the real problem is to keep these two logics in sync when it comes to changing the rules.
At the moment, what we do in the JS side is that we send all the requests for recalculations to the backend through ajax calls in order to use the calculator implemented in C#. This keeps our servers busy and I don't like the idea. I think that there should be a rule engine or something somewhere that we could utilise to keep the calculation logic in a language other than C# or JS and use/interpret it in both the front-end and the back-end.
Has anyone else faced the same problem? Any idea would be appreciated.
Faced the same problem and solved it by implementing the logic in javascript and then run it with https://jurassic.codeplex.com/ on the server. Works nicely.
You can try using Haxe to implement your rule engine and then cross-compile it to JavaScript and C#. This would give you a common implementation base for both and then - during compilation - your two different language outputs would be formed.
Disclaimer: I haven't used Haxe yet so I can't testify if it'd work for your situation but it supports both languages as targets.
You can use any decision-as-a-service platform. They usually expose decisions(bunch of connected business rules with relations and dependencies) as a REST API service. So you can simply interact with the service for execution and management of rules.
For example here is a sample how you can communicate with decision service for execution by passing input parameter values in JavaScript.
I'm in this project:
A web page that's gonna be used by the front-end company people to query and update data from a SQL DB.
I'm working with visual studio and the code behind (C#) is almost done, so the interactions between SQL and C# are ok.
My original idea was to work with ASP.NET which is familiar to me, but that's not gonna be possible. I have to switch to PHP.
So, today is my first day learning PHP, checking http://php.net/manual/en/index.php and a lot of things seem quite similar to ASP.NET so I guess it won't be that hard.
Anyways, some questions popped up quite fast as I wanted to script something else than a "hello world".
Is there an easy way to get/send C# variables from my class using a php page? I've read soemthing about using XML in order to do so, but still I'm scratching my head, is there another, easier, way to do this?
You have options.
direct integration. PHP can instantiate and use .NET objects . See the DOTNET library in PHP. So if you run PHP on Windows, and you expose your .NET logic according to the requirements of the PHP DOTNET infrastructure, then you can just call .NET classes directly from PHP. Some restrictions: PHP is built to integrate with the .NET 2.0 runtime. You can't build .NET 4.0 objects and connect to them from PHP.
synchronous network protocols. As others have suggested you can expose your C# logic via aREST or web services interface, then invoke those services from PHP using the curl library or file_get_contents(). The C# logic could be, but need not be, publicly exposed. In other words, you could make it accessible only from within the firewall of your app, so that no anonymous public access is possible. on the other hand your architecture may call for access to the same API from 3rd-party or user apps. In that case it needs to be exposed publicly.
in either case, public or private, you will want to use WCF or ASPNET MVC to expose these services implemented in C#.
asynchronous mechanisms. PHP can connect to MSMQ. See Using PHP to Open MSMQ Queues . Of course C# can do likewise. You could use MSMQ as a buffering communication mechanism between the two worlds. To do this you'd need to come up with a data serialization protocol, for the messages you put and get on the queue. JSON or XML would be appropriate choices here.
Database. If you are concerned about employing MSMQ as it is "one more piece of infrastructure to manage" you can also employ a database as a go-between. A shared database can be accessed by both PHP and C# and used as a message queue or communication conduit. PHP inserts messages in a MySQL Table, and the C# app could read and process them, then place reply messages in a different table. This would require some work by you to design the message formats, protocols, indexes, and request/reply correlation mechanism. But it relies on proven, existing technology that you already know how to use.
Finally, there is Phalanger. This lets you compile PHP onto the .NET Framework. This means integration between C# and PHP will be simple. I haven't tried this but it might satisfy your requirements.
I'm working on a project that has a website in Rails and a C# GUI that use the same database and data models. I'd like to share the (active)models between the two parts. Any ideas on how this is possible?
IronRuby is exactly for that.
You will need to run Ruby on Rails with IronRuby (you can do that via IIS too) and then you can call your C# assemblies like they were Ruby libraries.
Some resources to get you started:
http://IronRuby.net - official site with some documentation (not full but you will find some good info there)
http://www.IronShay.com - my blog with several posts about IronRuby. You can also contact me via its contact form if you need more directions
http://www.ruby-forum.com/forum/34 - The IronRuby forum/mailing list, questions answered by members of the IronRuby community and the team members as well.
The short answer is you can't without redefining them on the C# gui.
You can expose the controllers as WSDL/SOAP instead of the restful stuff, then you can have visual studio generate the proxies for you. C# is really bad at dynamic stuff so you can't just take the ruby models and reuse them in C# because they need to be compiled.
You can of course write your own proxy generation tool for the "restful" resources of rails but at the end of the day you'll have to duplicate the model code somehow.
Like shay says you can use IronRuby to bridge the gap but it depends do you want to reuse the ActiveRecord classes or are you using the website as your point to get to the data?
When you want to reuse the activerecord models then IronRuby is the way to go to talk to your database (but to get good integration with C# you would have to create strong typed wrappers around the models, so I don't really see the point).
First thing that comes to mind for me would be to expose RESTful web services from the Rails application, and consume those services in your C# client application. I don't know of a way to avoid duplication if you want POCO's in your C# application - maybe write a CodeSmith or T4 template that reads schema.rb and generates POCO's.
My friend and I are having a disagreement over an application development issue. It's a simple production management application.
According to my friend, the front-end stores data in XML, and a Java program will read the XML document, store it (at the back-end), and apply some business logic and again store the results into another XML document. And a C# front-end will display the result ( He wants to use sockets for communicating the status of XML ).
I think this is a bad idea. I suggested that whole application should either be written in C# or in Java.
Note: The application is standalone. It's not used over a network.
Have any of you tried this? Please share your thoughts :)
You're right and your friend gave a bad idea. In addition, from your question, I see there are several troubled issues, I don't know where to begin so I will just list them but not in any particular oder. But the ground rule for you to read on is you must agree that simpler is better as Einstein said "Things should be made as simple as possible but not simpler" (or something like that, I don't remember the exact quote).
The notion of front end and back end do not really apply to a desktop application. Rather, you want to use the MVC pattern for the separation of concerns. Wikipedia might be a good place to start learning or reviewing.
Why use of socket (which is totally unnecessary) if you don't have to. This is the first reason why it's a bad idea as you would not need using sockets if everything is done in language, running in the same process space (Your app is a desktop or standalone app).
Similarly, why XML (again unnecessary). No need because you can just pass Java or C# objects around. With XML, first there is the signal to noise issue as tags are added to the true data. Then there is the time to parse, to construct the XML, additional libraries potentially, etc. Thid would be all that code which are introduced in your friend's approach.
These are the most obvious reasons. There are other reasons from a manager's or company's perspective:
To maintain this application, the manager or company needs to hire 2 different skillsets. This might not be true as most programmers are multilingual anyway. But that's not always the case.
In term of deployment, now you force your users to have both the JRE and the .NET framework installed just to be able to run your application. And either of those is not exactly a small footprint.
Talk about making it complex. Either Java or C#. One really isn't a backend for another. They both 'do the same things' as languages. The only difference is whether you want to leverage the power of .NET, or the power of the immensely huge Java frameworks.
This is a desktop application that "is not used over a network"... I'm failing to see a need for a real "backend" at all.
Write the desktop application in a single language, and store your data in XML.
So your application is standalone and doesn't need to work over a network, but your friend insists on connecting the front and back ends of the app using sockets? Something is wrong with this setup, seems more complicated than it needs to be.
It sounds to me like your friend wants to use Java because he understands Java's XML handling framework better. Personally, I think interop between Java and .NET is overkill. You'll save yourself a lot of man hours and frustration by writing the app in a single language of your choice.
What your friend is suggesting is to keep things modular. It doesn't really matter what language you use, but if throw it together in one big project you might make it non modular.
For that type of app I would use one only one language.
It may be possible to leverage the power of C# desktop app on the front-end and Use Java Ejb+Web Service (Jax-ws) on the backend. C# apps can read SOAP wsdl to create the stubs and the interfaces to access Java backend implemented by Jax-ws.
What is the fastest way to share data structures between Java and C#? I want something where I can literally send a "car" object or a "foo" object and have it serialized and deserialized on both server and client.
WSDL (SOAP) is fairly interchangeable. If you want something less chatty, anything like Google's "protocol buffers", "ICE" (ZeroC), etc offer interchangeable binary serialization and code generation.
For .NET / C#, there are currently two viable protocol buffers implementations here; protosharp is essentially inactive and incomplete) - either would be fine, but neither currently has a complete RPC stack, so you'd have to handle message passing yourself.
You might be able to use IKVM, it's a Java-like environment on top of .NET; you could use Java serialization on IKVM and use interop to use the objects from "regular" .NET languages.
It looks like the IKVM seems like a good idea. But if that doesn't meet your needs especially since it is still in development. However, Uri's post points you in a good direction with the use of xml and passing messages, which can be built back together on either side.
Would you be able to use a SOAP web service on the server and have the client consume the web service?
The object's data structure would be described in the WSDL for the web service.