I am working on a new project for contract. Usually I go with c# asp.net and razor. The problem is, my portfolio says. C# C# C# C# over and over. I figure portfolio wise it may be helpful to have a little more variety. The other side is, a functional language seems to be an interesting approach since asp.net MVC3 is very function oriented as far as the controllers are concerned. So, has anyone tried using F# for this and did it turn out to be helpful or just get in the way?
I ask, because the controllers seem to benefit from being functional, while the models seem to benefit from an object oriented language.
I wrote some examples of using MVC3 with a mix of F# and C# and it works quite well and I also created a template that can be used as a starting point (which should appear on Visual Studio Gallery soon):
F# Empty Web Application
There are some nice things about using F# in the implementation of model/controllers:
F# types such as records make it very easy to implement the domain model
You can also use F# asynchronous workflows to implement async controllers (see this snippet)
A slightly annoying thing is that the support for LINQ in the current version of F# is a bit limited (writing complicated queries with lots of joins and grouping isn't easy). However, you can nicely use dynamic operator if you're calling stored procedures (see for example this blog post).
(I also wrote some articles about this that are not published yet - I can send you a draft if you drop me an email at tomas#tomasp.net)
Related
We're rewriting an old VB6 app in .Net and WPF. I'm going to be helping some co-workers who support the old app get up to speed in WPF and MVVM. My background is in .Net and C# so I don't know VB6, but I'd like to understand where they're coming from. What is VB6's native design pattern (assuming it has one)? Looking at the code it looks like it might be MVC, but is that right?
Was the original program a desktop program or a web program (classic ASP)?
Frameworks:
Desktop VB6 programs are similar to .Net WinForms. WPF is going to seem strange. MVVM is likely to be unfamiliar.
Classic ASP. Fairly similar to PHP, but with a way to call up DLLs. So, like PHP, some people developed organised frameworks of their own, and others wrote spaghetti. [Can anyone improve on this part of my answer?]
Do your coworkers like reading? You could recommend
Dan Appleman's excellent book for ex-VB6 programmers Moving to VB .NET. Now ten years old, but still very insightful. It doesn't cover MVVM or WPF. It targets VB.Net rather than C#, but most of it is still relevant.
Microsoft Visual Basic 6.0 Migration Resource Center (an excellent resource)
Other things to bear in mind: VB6 is an object-based language (it has objects, polymorphism, and interface inheritance through Implements, but no implementation inheritance). It is event-based, like .Net. Object lifetimes are deterministic because it uses reference counting. There are no generics.
It uses no design pattern. As a language, VB6 is a general one. The IDE and framework uses RAD approach, in procedural event driven style. The same thing applies to C#, except it uses object oriented event driven instead.
I have made an attempt to explain MVVM using VB6 here.
One tip I will like to add is with VB6 migration projects it is always best to refactor/modify code before hand. Although VB6 to VB.net conversion wizard in visual studio does a good job but there are too many pain points. Avoiding them by modifying VB6 is lot easier than fixing the issues in VB.net.
I'm making a web application that is quite a bit more complicated than others I've produced in the past. I think before I go much further I should try and get down a plan for the application as I currently have it.
I recently took a course in UML, but that doesn't seem particularly appropriate here - as while I'm using an object-oriented framework it is really the relationships between the Models, Controllers, Actions, Views and URL mappings I'm looking to document.
So my question is - Are there any software design applications out there that are particularly useful for documenting the structure/functionality of an MVC application?
On the basis of this I'd be hoping to write a testing plan.
Documentation is not for the creation of "testing plan" (whatever what means to you). If you want to test your application, you should have been writing unittests all along.
This sort of documentation is meant to alleviate the confusion in larges-scale applications. And the use of UML would be appropriate in this case, though there is no rule, that states you have to use all diagrams. But in your situation class or component diagram might be quite useful, with some sequence diagrams to illustrate more confusing parts of the application.
Also some ER diagram might help, if you have a complicated DB structure.
Please help - I'm getting lost!
I'm writing a small desktop application which has some controls and some screen. This should later be integrated with a small web site, also having some screens. The idea is to let the user edit videos and select images, and then share their results with her friends.
The desktop app is using C# WPF, the web site - ASP.Net MVC.
I read that growing the application past a few screens would be easier using MVVM. So I started searching and discovered Caliburn.Micro and MVVM.Light. I have downloaded some tutorials but, just as I was getting ready to deep-dive into the material, I found here on S.O. that there's also Prism, MEF, Unity, ReactiveUI - This is becoming too much!
I'm terrible at learning new things - It's taking me ages to study WPF and ASP.Net MVC. I don't want to study lots of new material only to find out later that it's not relevant. And I don't have an architect to instruct me.
So my question is: Could you put these frameworks and technologies in perspective, and suggest which I should focus on studying and using (esp. what can be later used with Windows 8)?
If you want to build an MVVM application (which you probably do for various advantages), then you want an MVVM framework.
I would recommend Caliburn.Micro, as it is straightforward to implement following the examples on the Caliburn.Micro documentation page. It also has a very compelling convention over configuration mechanism, and uses an Actions system to invoking verbs (methods) on your view models from the view. This is more powerful than any other mechanism I've seen.
Prism is quite a heavyweight framework which includes elements of MVVM design to help the implementation, as well as being particularly tailored towards building composite applications (applications that are built up of decoupled components within a hosting shell).
MEF is useful for these types of applications that need to discover plugins or extensions to the application (even after the application has bootstrapped), and can be used alongside an MVVM framework such as Caliburn.Micro. MEF can also be used for implementing inversion of control, but doesn't provide some of the core features found in other inversion of control containers, so you may decide to only use it to implement plugin functionality.
Unity is an IoC container, and would be used to implement dependency injection for your general application infrastructure. There are lots of IoC containers in the .NET space though, some of which offer either improved performance, additional features, or a more friendly API.
I don't know about ReactiveUI as I haven't used it.
If you're talking about maximising code reuse for a move to WinRT, then MVVM is a great choice.
PRISM already include MEF and MVVM logic :)
Ok little bit of explanation here:
MVVM stand for logic in your application. Actually clever way of decoupling of View, View-Model and Model. Don't know any best (?) framework to do it - you could check Catel if you want or MVVM Light but it just a tons of code from someone who understand the MVVM logic and just make it easy to implement it. You could actually try to write your own MVVM framework and see that 'there's no secret ingredient' - just the same repeating code and same classes, etc... Actually you don't need any MVVM framework to implement MVVM.
Once you learn and write MVVM you immediately run into question - How I NUnit test it in decoupling way (this is not trivial problem in Silverlight for example) - so here all IOC/Inject framework come into play. For example MEF. Consider following example to understand a big picture about Inject framework:
Project 'Shared', written in 'least delimiter' (for example Portable Library)
public interface IAmSharedInterface
{
string SayHello();
}
Project 'Main', reference only 'Shared' project
public class IAmMainClass
{
[ImportingConstructor]
public IAmMainClass(IAmSharedInterface SharedInterface)
{
SharedInterface.SayHello();
}
}
Project 'Implementor', reference only 'Shared' project
[Export(IAmSharedInterface)]
public class IAmImplementor: IAmSharedInterface
{
public string SayHello()
{
return "Hello from implementator class to whoever using it";
}
}
You see - there's no direct reference between 'Main' and 'Implementator' projects - all 'magic' happens in MEF/Unity build/resolve process. So you could easily run NUnit test on Main without using 'Implementor' project and 'Implementor' with 'Main'. There's also a scenario where other project could implement and export 'IAmSharedInterface' specially for testing purposes.
So back to PRISM - it have all (!) this. I know it's not easy framework to understand right away and it doesn't suitable for simple 'Hello World' programs but once you learn it - there's no way back. It just glue all the parts together and give you big degree of freedom in using whatever moq framework you want (for example Rhino).
Prism developing in Microsoft so (I hope) it will be supported not just in Windows 8 but in Windows 9 and in all future versions.
Whatever you asked it's all inside: MVVM, Inject, decouple/plug-ins, easy to read and test
To save adding to the detailed information above, I'll attempt to make life easy for you.
1) For now, forget about IOC / Dependency Injection / Plugin architecture. You say you're creating a simple app, so forget about this for now. Keep your code tidy and you can implement this later if necessary (it's good stuff).
2) Out of the frameworks you've listed I would suggest Caliburn.Micro. It's relatively straight-forward and lightweight. It wouldn't take you long to get up and running.
3) Create your model in a separate assembly which you can use for both your windows app and your MVC website.
Keep it simple and don't get bogged down with all the technologies.
This answer reproduces some abridged chunks of Rockford Lhotka's Blog article "Using the MVVM pattern requires a framework" which was cited in another answer.
It is sort of a meta-answer to this question (though it does contain a specific recommendation), but it seemed very useful to explain the role of a framework in MVVM in the first place.
There are three fairly
popular presentation layer design patterns that I collectively call
the “M” patterns: MVC, MVP, and MVVM. This is because they all have an
“M” standing for “Model”, plus some other constructs.
The thing with all of these “M” patterns is that for typical
developers the patterns are useless without a framework. Using the
patterns without a framework almost always leads to confusion,
complication, high costs, frustration, and ultimately despair.
These are just patterns after all, not implementations. And they are
big, complex patterns that include quite a few concepts that must work
together correctly to enable success.
...
Trying to do something like MVVM without a framework is a huge amount
of work. Tons of duplicate code, reinventing the wheel, and retraining
people to think differently.
At least with a framework you avoid the duplicate code and hopefully
don’t have to reinvent the wheel – allowing you to focus on retraining
people. The retraining part is generally unavoidable, but a framework
provides plumbing code and structure, making the process easier.
You might ask yourself why the MVC pattern only became popular in
ASP.NET a few short years ago...
Strangely, MVC only started to become mainstream in the Microsoft
world when ASP.NET MVC showed up. This is a comprehensive framework
with tooling integrated into Visual Studio. As a result. typical
developers can just build models, views, and controllers. Prior to
that point they also had to build everything the MVC framework does –
which is a lot of code. And not just a lot of code, but code that has
absolutely nothing to do with business value, and only relates to
implementation of the pattern itself.
...
Typical developers really do want to focus on building models, views,
and viewmodels. They don’t want to have to build weak reference based
event routers, navigation models, view abstractions, and all the other
things a framework must do.
...
In the meantime, Caliburn Micro appears to be the best MVVM framework
out there – certainly the most widely used [as of 2012]...
(Text copied inline for preservation reasons.)
I'm using VB6.
Data-aware classes refers to classes whose DataBindingBehavior or DataSourceBehavior property is set.
I learned this concept from MSDN and am wondering usually when should we use this technique of Data-aware classes? Or just like the Data Environment Designer which is just ignored by most developers?
The ability to create data-aware classes is just another aspect of Visual Basic's extensibility model. Along with the ability to create standard Classes and UserControls, you can create them as data-aware classes that can plug into VB's data binding mechanism.
You can wrap something like an ADO Recordset or ADO Data Control to create a more application-specific component, or you can create your own from scratch to provide data binding for some sort of out of the ordinary data. You can even create basic custom OLE DB Providers for unusual requirements by writing VB6 data aware classes in conjunction with the OLE DB Simple Provider (OSP) Toolkit.
Most of these things are rarely used today, because VB6 education is sorely lacking. A lot of programmers who learned by example shy away from data binding because they've found it frustrating. Most of this is a lack of understanding though. Instead we fall back on writing a lot of QBasic-like procedural code that sacrifices the power of VB6 event based programming.
You'll see the same thing in a lot of VB.Net and C# code loose in the wild. People seem unaware that event driven programming is actually much more important than the degree of "OOPiness" yet that's where the focus seems to be.
Programmers who understand the importance of this tend to have a lot fewer DoEvents loops in their VB6 programs and almost no gratuitous multithreading in their .Net programs.
I am as guilty as anyone of avoiding the Data Environment Designer and bound controls. I plan to become more aware of their use and capabilities though as well as making more use of VB6's Data Report Designer. These are powerful tools for writing data-centric programs, something I'm doing a lot more of lately.
There is no argument that Microsoft has dropped all support for VB6 development. But this doesn't say anything about the demand for it, which continues to be strong. If people have little to contribute to answering a question about VB6 they might spend their effort better elsewhere instead of shouting it down here. It is very sad that we never got a follow-on product - a newer VB supporting 64-bit development would be really nice. It just isn't in the cards.
Do you have any idea how old VB6 is? It's about ten years old. You should pretty well ignore anything you "learn" from VB6.
Some resources on VB6:
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7
Visual Basic 6.0 Resource Center (I didn't think such a thing existed)
Visual Basic History (I was right. October 1998)
Migration - Upgrading from Visual Basic 6.0
Product Family Life-Cycle Guidelines for Visual Basic 6.0 (it is unsupported as of March 2008):
Support will no longer be offered for Visual Basic 6.0 after nine years of general product availability.
Visual Basic 6.0 will no longer be supported starting March 2008.
All of this is from the following search: http://social.msdn.microsoft.com/Search/en-US/?Refinement=22&Query=vb6.
I think that feature has been ignored by most VB6 developers. Certainly I experimented with it once and never used it again. If you Google DataBindingBehavior or DataSourceBehavior there are relatively few hits.
I think what John is trying to communicate in his answer is that VB6 is not a good choice for new development unless you have strong reasons to the contrary - for example if your organisation already has a lot of VB6 experience and a lot of VB6 code to maintain, and no experience of other desktop programming languages. That sounds unlikely in your case, otherwise you'd be asking your colleagues the question rather than posting on Stack Overflow!
I'm looking for an asp.net control capable of formatting code written in certain programming languages (as in StackOverflow or the "Language" functionality in Notepad++), with automatic syntax highlighting/indentation depending on the language.
Do you know of any such control?
I don't know any asp.net control that does that, but you could use a JavaScript syntax highlighter, like this one : http://code.google.com/p/syntaxhighlighter/.
The main advantage is that it moves the rendering cost to the client side, which can be a huge gain for a highly-frequented website with a lot of code (eg programming forum/website like SO.. wait... they do that too, right ?).