My solution is split into 3 projects. Model, Services and Web. In my Service project, I'd like to use some F# features in it. Whats the best way to use 2 separate service projects, one for C# and one for F# and how would I structure these projects?
I think that the best option would be to split your Services project into:
Main C# project (especially if it contains some designer generated code)
An implementation F# library that is built using F# and exports the important algorithms in module or as classes (with a C# friendly interface).
This way you can use C# designers (which are generally not available for F#), but implement all the complicated functionality in F#. This approach is actually quite similar to the one I recomended recently on my blog when developing ASP.NET MVC applications in F#. The main application is written in C#, but all the interesting functionality is moved to an F# library and then used from C#.
Using ILMerge tool to merge two assemblies (as mentioned in the other referenced answer) may work, but it won't give you much benefits (the C# and F# parts won't be able to mutually reference each other), so it is essentially the same as having C# project + F# library.
Related
I'm starting to study Dart. It seems a nice language and in some aspects a real improvement over JavaScript. Since it claims to come with "batteries included" and to be meant for "structured web apps", though, I fail to understand how to actually structure a web app with it. Almost all the tutorials concentrate on language features, but Dart is quite simple and with many familiar bits, so that's the easy part.
Recently I fell in love with AngularJs. Now routing, two way binding, nested scope, clean separation of concerns... This actually means "structured" to me. But all the Dart examples I find are about selecting HTML elements and attaching listeners to them. This is old-style jQuery-like web programming and quite frankly the opposite of what I think of when I read "structured".
I don't want to compare a language and a framework and I know that Angular Dart is out, but I fear I'm missing something of vanilla Dart, because if it's all about a shorter syntax for lambdas, class based OOP vs prototypical OOP and the like, I don't see how it's supposed to be a game changer: there are many other languages that provide an alternative JS syntax (à la CoffeeScript) and compile to it, and they don't come at the price of losing a perfect integration with existing JavaScript libraries and tools.
Sure, it has optional static typing, which may be great, but this comes more to a matter of preferences. I'm a full time Python and Ruby developer and I'm perfectly fine with dynamic languages. Is this what they mean by "structured"?
Thanks for any clarification that will eventually come.
I work on AngularDart and have some experience structuring web apps.
When building a web app in Dart you would pick a web app framework, for example AngularDart or polymer.dart. Web app frameworks have a lot of opinion which is something that doesn't fit in the core libraries. In that respect, "vanilla Dart" is fairly vanilla.
Since I'm most familiar with Angular, I'll discuss the Angular + Dart combination. However, the rest of this post is also true for polymer.dart.
Angular provides a lot of structure to your app. We've been able to provide a similar structure for both Dart and Javascript. The concept of directives, data binding and dependency injection exist in both.
Dart provides more structure and we've been able to use that structure while building AngularDart. e.g. the directive API is defined in terms of annotations which means that IDEs understand them and can help you code.
There are a number of "structure" features in Dart. One of my favourites is tooling. With types and annotations comes better tooling support.
Types in Dart are most useful when combined with tools. Auto-complete is great but for large web projects, static analyze is even better. For example, in AngularDart, since directives are annotated classes, we can assert that the annotation is correct. Even more interesting is the potential to build tools. In AngularDart, we have a tool that extracts and analyzes all directives. This type of tooling is possible in Javascript but easy and supported by the language in Dart.
libraries, packages
integrated dependency management with pub package manager
class based instead of prototype based
scopes of variables as one would expect in a modern language
static syntax check
better tooling support like code completion
If I'm familiar with F# events already, and I don't plan to have too much C# interop, are there significant reasons to consider using the Reactive Framework?
I think there are two main differences:
Firstly, there is a difference between the IEvent<'T> interface (and functions in the Event module) and the IObservable<'T> interface (used by functions from the Observable module and Reactive Fx). The difference has been discussed on SO earlier.
Reactive Framework is a more complex library, so it implements many combinators that are not available in F# in Observable or Event modules (although there is a open-source project that adds many of them)
The summary is, you should prefer functions from the Observable module. If it has everything you need, there is no need for Reactive Framework. If it does not, then you'll need either Reactive Framework or MiniRx (which, I believe, is sometimes more efficient too).
The F# Event module dates back to 2006, so I think Reactive Framework is clearly inspired by that, but it does not fully replace the F# functionality (mainly because it is not standard part of .NET or F# core).
Wiithout wanting to create an open ended question....
F# is currently absent from the Windows 8 dev preview. There is a mapping layer in WinRT that wraps core objects into CLR objects for C# / VB or through other mappings for different languages.
Given that this model does not force languages through the CLR, my question as a functional programming novice is: Is this any benefit to F# (having a direct mapping to WinRT without the CLR layer could further reduce mutability, more native list types) or would it make sense to have a more purely functional language join the ecosystem and leave F# where it is (bearing in mind that interoperability is no longer restricted to CLR languages)
If anybody creates a pure functional mapping for WinRT, that would be quite interesting. However, there is no single right way of doing functional library for something (just like there is no single right way of doing object-oriented library).
The great thing about F# is that you can easily write your own functional wrapper over the underlying (imperative) API. For WinRT, this means that we can easily implement different functional approaches to WinRT programming, without having to write any COM-based mappings.
Is there any framework or code generator for data access in Delphi based on layered architecture?
Delphi has already Multi-Tier / Layered architecture available since early versions. You were never limited to RAD components.
DataSnap is certainly the de-facto standard version of building such applications. See e.g. this article from Embarcadero.
Other Service-Based frameworks written on Delphi are available (DataAbstract,
RemObjects, KBMMw, Midware, WST, Synopse, Spring).
ORM framework are a good way of creating multi-tier separated applications (e.g. InstantObjects, DObject, tiOPF, GFramewok, Bold, Synopse, hcOPF, DelphiORM..). Some of them even allow to build Services above ORM. See for instance our Open source framework.
You can have a look at the various Object Persistence Frameworks out on the market. We have been using tiOPF for some years and are very happy with it. Although it has a very steep learning curve.
There are others available as well, like hcOPF
Is it possible to do Aspect Oriented Programming in Delphi? I would be interested in native support as well as third party solutions.
I don't have a specific problem I want to solve with AOP, but am simply interested in studying AOP.
AOP depends on two things:
The ability to inject additional code into an existing unit of code
A mechanism to place conditions on where code should be injected.
This is commonly referred to as code weaving. It is a specialization within the larger study of program transformation.
JIT compiled languages have more options for implementing code weaving than statically compiled programs because more information is retained in the bytecode/IL. They also support reflection, which offers the ability to manipulate code at runtime.
Delphi.NET and Prism have the same access to these capabilities as any other .NET language.
There are two AOP frameworks for Delphi Win32 that I'm aware of. The first is MeAOP, which has already been mentioned. The second is Infra. Both projects take a similar approach to AOP. They use a combination of RTTI and clever pointer manipulation to intercept method calls so you can run additional code before or after the method call. You define your cross-cutting feature as a subclass of the framework's AOP class. You register the methods you want intercepted by passing the method name as a string argument to the AOP framework.
Both frameworks are still actively developed and are actually larger in scope than just AOP. Unfortunately documentation is somewhat sparse (and in Infra's case mostly in Portuguese)
Another project attempted AOP through source code weaving back in 2004 with some success. Basically they built an aspect weaver on top of a general purpose program transformation tool called DMS and used it to inject code into delphi source files prior to compilation. Their aspect oriented language was primarily influenced by AspectJ.
http://www.gray-area.org/Research/GenAWeave/ has links to the original paper and presentation as well as some videos of the transformation process.
It may also be possible to use runtime code instrumentation to accomplish this as well. Its a technique used by some profilers to inject counters and stack traces into running code without modifying the original source. A similar technique could be used to inject crosscutting concerns into a statically compiled executable. The PinTool project is a good example of this.
ClassHelpers in the later versions of Delphi allow some very limited level of AOP type behavior. You can use ClassHelpers to inject behavior into other classes without descending from them. It allows overriding existing methods and then optionally calling that existing method.
The limitation is you must declare a ClassHelper for a specific class and it descendants. Additionally a class can only have one ClassHelper.
These are similar to Extension methods in C#.
The DSharp library features AOP:
https://bitbucket.org/sglienke/dsharp
More info can be found at: https://bitbucket.org/sglienke/dsharp
Also have a look at TVirtualMethodInterceptor.
It's in the RTL since Delphi 2010 and allows you to do OnBefore, OnAfter, etc. calls on all virtual methods on a class.
This call alone should cover must of what you need using Rtti, not weaving which is much faster than run-time weaving.