We are Silverlight Unit Test Framework for testing.
Which one will be better for my team? Rhino Mocks or Moq. No one has any experience with using a framework like this.
What are the pros and cons of using each framework in this environment?
Take a look at both, and see which syntax suites you and your teams skillset.
Rhino Mocks has been around for nearly 4 years, and supports a couple different symantics. The record/playback is the oldest, and the Arrange Act Assert (AAA) is the newest. I would say that in the community, Rhino Mocks is the standard framework due to how long it has been around, and how easy it is to find examples, documentation, and help with.
Moq is really about 1 year old, and relies heavily on .Net 3.5 syntax, like lambdas. I think because of how new it is, it might be harder to find people who have used it, and get help with it.
More important than the framework you choose, is getting an understanding of how mocks help you test, and also how they can change the way you think about designing systems for testability. In the end, the framework doesn't matter, the experience and knowledge matters.
There's not much impact of Silverlight itself on the frameworks, and using them is not much different than doing so in full .NET
RM is said to have steeper learning curve, and MoQ allegedly has cleaner API, but RM on the other hand, has been around for much longer, and probably supports more corner-case scenarios.
I'd suggest to spike with both, and choose whichever you find suits you better.
I prefer Moq for its lamba-like syntax.
I find it very difficult to use Moq with ref/out parameters in functions setup's... Switched to Rhino because of this
Related
I'd like to start using IoC Container in an existing WPF application.
I need good performance, but from what I read, performance is really not an issue with most containers.
What I need most is a very easy to use container, that can be easily integrated into my app. I read recommendations about StructureMap (and the syntax looks great), but in their site it seems that there were no updates in the last 3 years, so I'm having some doubts about it.
Please provide recommendations with basic usage code samples (initialization + usage).
Edit
I'm not looking for a complete framework. I only need the IoC container ability, so many other alternatives exist. The last relevant discussion I found here is a few years old and I'd like to refresh it.
The answer really depends on personal preference and the details of your use case. Anyway, after using Unity, MEF (I know, not a real IoC container) and writing some individual solutions, I am now using Autofac and like it a lot. It is very easy to dig into and continuously reveals its advantages the longer you use it. It provides a fluent interface and is fast, compared to other frameworks (btw: The performance of your container can be a very important issue, depending on what you want to do). For usage and samples of Autofac see the link above.
Why I like it:
Easy to get into
Fluent interface
Supports open generics
Supports assembly scanning
Interoperability with MEF and other frameworks
Fast enough (Performance comparison of IoC containers)
Still, this is personal choice and there are other good solutions around, which might even be better for your special case.
And, more or less off-topic, I can recommend this article, especially the second half, for general considerations. It helped me a lot. So, just in case:
Article by Martin Fowler
Structuremap aint dead.
We are using it for our new green field project, and when v3 is out we may migrate to it. ATM using 2.6.4.
Your question is a shopping-list type question so it won't stay open long.
There are a number of IoC type frameworks, some of which require declarative or programmatic manipulation to do their work, some of which use code semantics to wire things up.
I would suggest you start with Unity1 until you get into the swing of things, then look to branch out into some of the more exotic frameworks when you can appreciate the differences between them.
1 Here is a good recent intro article: Visual Studio magazine: Creating Modularity with WPF, Prism and Unity
I can't find Rhino Mocks executables for Silverlight.
I've googled a lot. It should be here http://ayende.com/blog/3843/rhino-mocks-3-5-silverlight. But link does't work anymore.
I think the latest repository is here on GitHub.
The link is broken for quite a while now (at least half year, might be more). Myself, I have never seen actual RhinoMocks executables for Silverlight (been looking for them too!). Since you got the same problem, perhaps it will be a good idea to try out one of the new mocking frameworks which both support Silverlight and are constantly gaining on popularity:
FakeItEasy
Moq
If you have some RhinoMocks background, using either of them will be easy and intuitive.
What is the best scala-like persistence framework available right now?
Hibernate works, but it's not very scala-like. It insists on using annotations, no-arg constructors, doesn't work with anonymous class instances, doesn't work with scala collections, has an outdated string-based query model, etc.
I'm looking for something that really fits Scala. Does it exist? Or do I have to make it?
Squeryl is a strongly typed, LINQ like persistence framework written entirely in Scala.
In any case, it looks very promising. There's also ScalaQuery by Stephan Zeiger, which has a similar approach.
I haven't tried these two out yet, but will likely do so in the very near future.
Old question and that's probably why no one mentioned Slick at the time, but that's a good choice nowadays. It's developed by Typesafe, so there's some assurance of quality and continuous development that other frameworks might not have.
Anyway, this link might be a good source for anyone looking for other options: http://manuel.bernhardt.io/2014/02/04/a-quick-tour-of-relational-database-access-with-scala/.
Lift has a persistence framework in scala, but it's integrated with the web framework and is a bit specialized.
I've not gotten a chance to evaluate it personally, but it looks like eBean is very Scala friendly. It even supports Scala types (as of Release 2.6.1).
I'm trying to build a line of business application using Silverlight. I felt like I was doing good then someone asked some questions. Immediately, I became really confused. I see discussions around Prism, Unity, and the Managed Extensibility Framework. However, they all look like they are trying to solve the same problem. Am I nuts? How do these three items compare / contrast with one another?
Thank you!
I recommend listening to the Herding Code podcasts with Glenn Block. (Part 1 and Part 2). He goes into this exactly subject, in much more detail than we can answer here.
That being said -
MEF and Unity are the two things that have quite a bit of overlap. Prism, in its default form, uses Unity for its dependency injection. You can use Prism with MEF, if you like, instead.
Prism is designed more for building composite applications. MEF, on the other hand, is about extensibility. There is definitely some overlap in goals here, but the basic driving factor is different.
In Prism's case, it's all about organizing known code.
MEF, on the other hand, is about discovering new code, and injecting it appropriately.
The newest guidance I've seen, which I fully agree with, was just posted on Glenn Block's blog: "If you are starting fresh you can use MEF for modularity, and general aspects of your composite app. Where appropriate you can pull in Prism bits."
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
There was this post today that discusses two scenarios where MEF and Prism work together to provide solutions. Each scenario leverages features that are not found in each, with 80/20 rules for those features that they do share.
Although there is overlap, the essential differences from a 30,000 view are
Unity is a IOC container. Use it to make your app more loosely coupled
Prism is gear toward making your UI more loosely coupled. As Reed mentioned, it uses Unity to help do this.
MEF is meant to make your code extensible. This helpful when having to interoperate with code that will be written by someone else. An example is if your application will support plugins.
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?