I have a library with some objects that I use both from C# and JavaScript. There are several objects, let's call one of them Foo, with the same basic implementation in C# and JavaScript. When I want to transmit an object of this type from the server to the browser, I simply call Foo.ToJson() to serialize this object to JSON and then revive the object on the browser side with a safe eval() operation.
This is all well and good, but the library is becoming complex and the need to keep the JavaScript and C# code bases synchronized is increasingly difficult and error-prone. I'm interested in ideas for simplifying this architecture or making it easy to maintain. Thoughts?
You could look at using script#: http://projects.nikhilk.net/ScriptSharp
Since your classes are all coded in C#, you could reuse the same .cs file for both the server and client projects. that way, when you make changes, it's automatically compiled into the javascript :-)
have you considered making your "shared code" into a web service, this way any of your applications can access it, and you can make everything distributed to help with performance.
Just one solution.
http://en.wikipedia.org/wiki/Web_services
Make the parts of your app that overlap as data-driven as possible. At a certain size, it's easier to have a state-machine interpreter running on both sides that can parse the same data.
Write the code once. There are a couple C# to JavaScript compilers you can look into. Script# and jsc.
Use DTOs. Data Transfer Objects.
This way if your JScript or C# objects change, your DTOs don't necessarily have to change unless that property is immediately required at the client. And even then, you have a clear separation of what is intended to be Serialized and what is not.
Dave Ward at Encosia speaks a lot about this.
Related
I am creating a grid application which requires me to send software packets that wrap a class out to participating nodes within my grid.
The first idea that I came up with was to have the master nodes contact each node (running a Windows service) and send an assembly containing a class which adheres to a common interface along with a .config file containing, well, configuration information.
Is there a better way to do this? Aside from the discussion on whether this should be a push or a pull, what's the best way to get what is effectively a software update out? It would be great if I could use something similar to a WCF service called by the client nodes, but that would, of course, leave the real processing on the master node, which would effectively uncluster my cluster.
You can send the assembly bytes and load them directly into the runtime. It work well for managed code. I'm not aware of a better way to do this. And yes, use a push model :)
This seems like a valid approach. This is essentially how most .NET plugin models work.
The only other approach that I can think of would be sent script files back and forth. You could make your own custom DSL, but I think that that would be overkill. Using something like Iron Ruby or Iron Python would be a lot simpler, as well as a lot more powerful. Another thought would be to send PowerShell scripts.
I have never tried this, but it's also possible to send C# or VB files back and forth and then compile them when they need to be run. However, I see little advantage of this over the previous two suggestions.
Can you give me some advice on how to best ensure that two applications (one in C#, the other in Java) will be compatible and efficient in exchanging data? Are there any gotchas that you have encountered?
The scenario is point to point, one host is a service provider and the other is a service consumer.
Have a look at protobuf data interchange format. A .NET implementation is also available.
JSON for descriptive data, and XML for general data types. If that is not efficient enough for you, you need to roll your own codecs to handle the byte ordering difference between C# and Java.
Rather than focus on a particular technology, the best advice I can give is spend time focusing on the interface between the two (whether that be a web service, a database, or something else entirely). If it is a web service, for example, focus on creating a clear WDSL document. Interface, interface, interface. For the most part, try to ignore the specific technologies on each end, outside of some prototyping to ensure both languages support your choices.
Also, outside of major roadblocks, don't focus on efficiency. Focus on clarity. You'll likely have two teams (i.e. different people) working on either end of this interface. Making sure they use it correctly is far more important than making things just a little faster.
If you have Java as a webserver, you can use Jax-WS ( https://jax-ws.dev.java.net/ ) to create webservices and WCF for .Net to connect to the Java Webserver..
You can use something like XML (which isn't always that efficient) or you need to come up with your own proprietary binary format (efficient but a lot more work). I'd start with XML and if bandwidth becomes a problem, you can always switch to a proprietary binary format.
Something like SOAP (Wikipedia) is supported by both C# and Java.
We use C#/VB.Net for our Web interfaces and Java for our thick client. We use XML and webservices to communicate between the database and application servers. It works very well.
Make sure that you use a well defined protocol in order to communicate the data, and write tests in order to ensure that the applications responds according to contract.
This is such a broad question but I'd recommend focusing on standards that apply to both platforms; XML or some other standard form of serialization, using REST for services if they need to interoperate.
If you use XML, you can actually externalize your data access as XPath statements which can be stored in a shared resource used by both applications. That's a start.
Currently the project I'm working with does not have completely fixed models (due to an external influence) and hence I'd like some flexibility in writing them. Currently they are replicated across three different layers of the application (db, web api and client) and each has similar logic in it (ie. validation).
I was wondering if there is an approach that would allow me to write a model file (say in ruby), and then have it convert that model into the necessary c# files. Currently it seems I'm just writing a lot of boilerplate code that may change at any stage, whereas this generated approach would allow me to focus on much more important things.
Does anyone have a recommendation for something like this, a dsl/language I can do this in, and does anyone have any experience regarding something like this?
This can be easily done with ANTLR. If the output is similar enough you can simply use the text templating mechanism—otherwise it can generate an abstract syntax tree for you to traverse.
I have seen a system that used partial classes and partial methods to allow for regeneration of code without affecting custom code. The "rules engine" if you will was completely generated from a Visio state diagram. This is basically poor mans workflow but very easy to modify. The Viso diagram was exported to XML which was read in using powershell and T4 to generate the classes.
The above example is of an external DSL. I.E. external to the programming language that the application runs in. You could on the other hand create an internal DSL which is implemented and used in a programming language.
This and the previous article on DSLSs from Code-Magazine are quite good.
In the above link Neal Ford shows you how to create an internal DSL in C# using a fluent interface.
One thing he hasn't mentioned yet is that you can put this attribute [EditorBrowsable(EditorBrowsableState.Never)] on your methods so that they don't appear to intellisense. This means that you can hide the non-DSL (if you will) methods on the class from the user of the DSL making the fluent API much more discoverable.
You can see a fluent interface being written live in this video series by Daniel Cazzulino on writing an IoC container with TDD
On the subject of external DSLs you also have the option of Oslo (CTP at the moment) which is quite powerful in it's ability to let you create external DSLs that can be executed directly rather than for the use of code generation which come to think of it isn't really much of a DSL at all.
I think you are on the right track.
What I usually do in a situation like this is design a simple language that captures my needs and write a LL1 (Recursive Descent) parser for it.
If the language has to have non-trivial C# syntax in it, I can either quote that, or just wrap it in brackets that I can recognize, and just pass it through to the output code.
I can either have it generate a parse tree structure, and generate say 3 different kinds of code from that, or I can just have it generate code on the fly, either using a mode variable with 3 values, or just simultaneously write code to 3 different output files.
There's more than one way to do it. If you are afraid of writing parsers (as some programmers are), there is lots of help elsewhere on SO.
I've got a system that has Java server side objects and C# client objects. The objects can be modified in both sides of the system and so have business rules attached to them. The thing is currently the business rules only live on the server side, and I really want to avoid having to contact the server every time I want to verify the objects.
So ideally I want to have shared business rules that can be used in both C# and Java, so when a change is required I only apply it in one place (and obviously deploy in 2).
Has anyone any suggestions on how I could go about this?
This may sound terrible at first, but you could in fact consider coding the business rules in javascript.
There are javascript engines available both on the java and .NET platform. That way, by hosting a (different) javascript engine both on the server (java) and client (C#), they can both execute the same javascript to enforce business rules.
Think of it as your business rules language of choice. It's not a bad choice for the task either, as it is terse, flexible and well known.
I have done something similar once, to set up flexible game rules in a java-based game. Javascript engines are surprisingly simple to set up, and nowadays they're getting pretty fast too.
Try using IKVM
I am used to writing C# Windows applications. However, I have some free hosted PHP webspace that I would like to make use of. I have a basic understanding of PHP but have never used its object-oriented capabilities.
Is there an easy way to convert C# classes to PHP classes or is it just not possible to write a fully object-oriented application in PHP?
Update: There is no reliance on the .NET framework beyond the basics. The main aim would be to restructure the class properties, variable enums, etc. The PHP will be hosted on a Linux server.
PHP doesn't support enums, which might be one area of mismatch.
Also, watch out for collection types, PHP despite it's OO features, tends to have no alternative to over-using the array datatype. Check out the sections on the PHP manual on iterators if you would like to see beyond this.
Public, protected, private, and static properties of classes all work roughly as expected.
A huge problem would be to replicate the .Net Framework in PHP if the C# class usses it.
It is entirely possible to write a PHP application almost entirely in an object-oriented methodology. You will have to write some procedural code to create and launch your first object but beyond that there are plenty of MVC frameworks for PHP that are all object-oriented. One that I would look at as an example is Code Igniter because it is a little lighter weight in my opinion.
I don't know about a tool to automate the process but you could use the Reflexion API to browse your C# class and generate a corresponding PHP class.
Of course, the difficulty here is to correctly map C# types to PHP but with enough unit testing, you should be able to do what you want.
I advice you to go this way because I already did a C# to VB and C++ conversion. That was a pain but the result was worth it.
If the problem is that you want to transition to PHP and you are happy to continue running on a windows server with .NET support you might consider wrapping your code using swig.
This can be used to generated stubs to execute from php and you can then go about rewriting the .NET code into PHP in an incremental fashion.
This works for any of the supported languages. ie. you could incrementally rewrite an application in c++ to java if you really wanted to.