Comment by spamizbad | Hacker News Reader

Comment by spamizbad | Hacker News Reader

Parent Full thread

> I guess my question would be, what's an example of this.

One example that stands out to me in the whole concept of strongly typed views. Nice in theory, but ultimately tightly coupling your view to your model (or your model to your view, depending on your perspective) is very Webforms-ish. You can tell they put in place these practices to ease adoption among the current crop of vanilla ASP.NET developers.

Another example is being able to quickly bake-in full-text-search into your application. With Python/Django you can use something like Haystack. Ruby has equivalents. With MVC, what are your options? Do it by hand with Lucene.NET? Get there a bit faster with .NET connector for Solr? This is more of a .NET ecosystem complaint, but ecosystems matter.

> And for me the tooling makes my life much easier.

I agree. Working with Visual Studio is great. With that said, I missed being able to "edit on the fly" my Python code and immediately pop into the browser to check, so now I just have a build script that builds and stages my projects automatically on an IIS server so I can accomplish what I got for free in Python/Django.

I think strongly typed views are an area where things fall down due to lack of guidance rather than design. I don't think a view model is the same thing as the model in MVC.

In my MVC apps, I use them pretty much exclusively, but they exist completely independently from my application model (they represent compositions thereof). This really only makes sense in apps of a certain scale, though, so having the option not to use them, or to use dynamic views (not sure if they count as strongly typed, but they are a weird middle ground) is definitely useful.

What's wrong with strongly-typed views? I appreciate having the compiler do type checking for me so that I don't have to write a bunch of unnecessary unit tests to do the checks, and it makes refactoring straightforward. More importantly, on projects with larger teams, a strongly-typed view model means other developers can quickly understand expectations without having to dig into the view details, and designers can work on the view according to a fixed, documented and explicit contract independent of the progress of the implementation.

If you're working on a small, simple application with 2 or 3 other developers maybe it's not that big a deal, but on medium+ sized line of business application teams with 20+ developers it makes a massive difference when you need to fix somebody else's bug in an area you don't have much background in.

And what problems did you have building full-text search into your application? I used SQL Server + Full Text catalog for the first time ever recently and I was up and running in a few minutes. That being said I'm not familiar with what Lucene offers, so maybe you have something in mind that SQL Server does not support.

In reply to your first point, you should really consider using ViewModels. It a) makes views cleaner because it gives you a place to put formatting, and b) provides for some element of decoupling your views and models.

If you're passing models directly to views with Django, don't you have exactly the same problem?

Reply on news.ycombinator.com