Hi Martin,

We use a similar setup.

1. VS and git
2. Nuget as much as possible
3. We use a shared DB and run a local IIS. For sharing media between developers machines we use BitTorrent Sync
4. We use razor
5. We try to use surface controllers for almost everything
6. We use routehijacking in all our projects, but we specify a default controller so we don't need to create a controller for every doctype. This is because we use Donut output caching.
7. API's are used for ajax requests
8. depends on the project
9. Only use angular in the backend at the moment

Hi Dave

Have you been cherry picking bits and bobs from the hybrid framework? Would I be correct in assuming this? If not, have you taken a look at it for use in a project? I haven't quite got that far yet!

What on earth is donut caching? How do you integrate it in Umbraco and what are the benefits?

One question which has baked my brain for some time is why use DI/Autofac at all in an Umbraco project? I can see it being useful if you are strapping on business logic that may exist outside of the Umbraco schema. Is the idea that it makes structural changes to doctypes easier to consume in code via DI? Again what are the benefits beyond, just using surface controllers/views and IPublishedContent? DI is supposed to be easier to test, but by your own admission you say that you've struggled overall unit testing in Umbraco, so i'm interested to understand your motivation for using DI?

Here's couple of suggestions I can make regarding improving your own workflow...

IIS Express & LocalDB completely removes the need for having full blown versions of SQL Server and IIS (which is OS version dependent anyway) on your workstation, lightening the load enormously. Additionally you can add the localDB MDF file to your TFS/Git repo too. uSync is by far the best tool to ensure developer changes are kept in sync. We use Microsofts SyncToy to keep media sections up-to-date. Finally, as I have a number of projects that run on a common codebase, I tend to build my Controllers, API code, Views, XSLT, css, js etc in a seperate project, then in IISExpress setup a virtual directory avoiding the need for build events, at least until deployment time :-). I also use DLL injection so that the controllers work with whatever project they're attached to.

Sorry for the rapid fire questions. I hope you have a little time to reply.

Many thanks

Martin

Hi Martin,

We are using a similar setup.

1. VS and Mercurial, git sometimes
2. Nuget as much as possible
3. We are using local DB and run a local IIS for each developer, sync content types with uSync. We don't sync media with the developers at all.
4. Razor
5. We are using surface controllers only for handling form requests, for data retrieving we are using API
6. We use route hijacking in all our projects

Another is the same ))

We don't use DI/Autofac at all in an Umbraco project, we haven't a lot of logic in one place, can you share how do you want to use this ? What benefits ?

We are using caching as much as possible, very convenient way to cache static parts of page with Html.CachedPartial helper method.

Thanks, Alex

Hi Martin, Alex,

We indeed use some practices from the Hybrid Framework. But don't use the framework as the base of your websites.

Donutcaching is something I picked up from the hybrid framework. It allows you to cache the output of a controller, so if you use routehijacking it will cache the entire page. So you website will have extreme performance. You can also exclude some controller actions from the cache if you want.

You can read more about that here : https://github.com/moonpyk/mvcdonutcaching

We also use usync. But in a different manner. For source controlling umbraco configuration and for easier deployments. If I find some time I want to look at chauffeur because this does something similar, but without the dependency on a httpcontext so you can run it from a console app.

We use DI for all external dependencies. In bigger projects we sometimes use it also for Umbraco content. The idea is to keep our views and controllers "dumb" about where our model is comming from. 

We prefer to keep our local environments as close as possible to live environments. So that's why we use a shared SQL server. This also has the advantage that all devs work with same content.

Putting SQL CE in git is bad practice in my opinion. Because I binary file you can't keep track of changes. And will give you a hell of time merging code from different developers.

Dave

Hi Dave

All excellent advice, thanks! I completely agree on the DI front, especially if you're using models which may have BL outside of the Umbraco scope. I'll look into this further.

On the SQL front, I chose localDB because it's essentially a full version of SQL server, but without all of the resource requirements of the full product. Its even more lightweight than SQL Express edition as it runs up as required (ie when you run from within VS) and comes back down when you stop debugging. It has the benefit of being accessible from all of the VS SQL profiling tools and SQL Management studio. localDB is built into the VS2013 installation, so it's not something you need to "add" to use. Dont confuse localDB with SQLCE, two completely different beasts! http://blogs.msdn.com/b/jerrynixon/archive/2012/02/26/sql-express-v-localdb-v-sql-compact-edition.aspx

We only store the localDB MDF in our repo for sharing purposes, which is why we use uSync to ensure developer changes are kept in sync. OK so it doesn't do content, but we tend to strap on as much as we need to build and test and periodically check-in if there's changes to content for any reason. One final benefit worth a mention is because localDB is genuine bonefide SQL edition, albeit specifically for developers...You can (and we do) run a DB backup from the localdb MDF or attach the MDF to an actual server later on. We often, pull down backups of our live environment and drop them into localDB to continue development on a site where there's lots of content available to test against.

Regards

Martin

Hi Martin,

Thanks for the local DB clarification. I was indeed confusing this with sql ce.

You talked about Automapper. We just introduced in our latest new sites and are amazed by the power of it. Especially when you start using custom valueresolvers and typeresolvers.

Dave

Hi Dave

Is Automapper demonstrated in conjunction with ModelsBuilder / HybridFramework? I'm sure I read something mentioning its use.

I had a little dig around 'our' and came across this post which helped me a little.

https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/61929-Ditto-or-Stephan-Model-Builder

Martin.

Are somebody using uSiteBuilder ? A lot of companies are still using it, but I struggled with performance problems of it. Automapper is great when you are converting uSiteBuilder model to POCO class or ViewModel.

Thanks, ALex

What about performance best practices ? I like to create sites with 50ms or less in response, it's really hard sometimes with Umbraco and a lot of logic on the main page.

Hi Alex, Martin

Drop uSitebuilder. We had a go at it and it caused more problems than it had advanteges.

Have a look at this session from Pete Duncason on Why code first is bad : https://www.youtube.com/watch?v=Hr1irQ0h5J8

For performance I recommend using Donut output cache. We have sites rendering html in less than 50ms.

Automapper is great tool to map one object type to another.

We use it to map for example models created by ZBU to viewmodels.

Dave

Hi Dave

Yes, I watched that video yesterday and confused modelfactory methods as "code-first" approaches. But the two are not the same.

"We use it to map for example models created by ZBU to viewmodels." - can you be more specific about this?

Thanks

Martin

Hi Alex

Performance optimisation is another interesting area. I've always felt Umbraco has a really good (and quite heavy handed) caching mechanism. It can get in the way at times during development, so thats never really worried me.

Our main webs server has been up-scaled in terms of CPU/Memory so I suspect we are benefiting from this somewhat so again I dont have any issues there.

The rest is code and resource optimisation. We use Shandems CDF for bundling and minimising our JS/CSS, although it annoyingly generates a lot of errors in our logs so I may switch to something else. The only other area where I need to improve is changing from ImageGen to Slimsy as the latter is the better option for mobile respsonsive development.

50ms, Is that in total, after everything is loaded with the cache disabled? I think thats a bit over optimistic as an average. Currently our main UK site averages between 200ms if the image count is low upto 1 second if there's a lot of images to load. If I switch Chrome to a "good" 3G throttle the pages average around 3 seconds, but I know there would be an enormous improvement once I introduce Slimsy. I should note, a significant proportion of our builds still use XSLT as part of our modular rendering, but with razor views & a few partials for the templates instead of masterpages and user controls.

Martin.

Hi Martin,

We use the default ASP.NET bundling. You could use the Optimus package for that to make it easier.

When I say less than 50ms i'm only talking about the page. No other resources like images, css, etc..

Using donut caching we can even reach this under heavy load.

Dave

Thanks for you recommendations.

"We use it to map for example models created by ZBU to viewmodels." - can you be more specific about this?

Why are you converting ZBU models to view models ? We used ZBU models as viewmodel, what is bad with that?

50ms for server answer isn't very optimistic, it's real and simple sites should answer 50ms and less.

Alex

Hi Dave/Alex

Our server is managing to deliver the main document (the first request) in less than 50ms on a lot of pages (cache disabled). But I would say that it averages somewhere between 50-100ms. I'm thinking thats pretty good going, but there are a lot of variables to consider overall so as a rough benchmark, I think we're doing OK around the 70ms average. As mentioned before I just need to optimise my images better and make another attempt at reducing the number of requests to images in our CSS bundle.

Dave, in response to Alex's comment  -> Why are you converting ZBU models to view models ? We used ZBU models as viewmodel, what is bad with that? 

I am interested to learn why you do this too?

Martin

Hi Alex, Martin

Let's say we have news section in the site existing of 2 doctypes : NewsOverview and NewsItem. 

So the newsitem is a ZBU model that contains several properties like title, summarytext, publishdate, content, author, categories

We have several ways of displaying the news:

A list top newslist on the homepage showing just title and publish date

A list on the news overview displaying title, publish date, author, categories and summarytext

Newsdetail page displaying all the properties.

So we have different viewmodels for all 3 representations.

We use automapper to map the ZBU newsitem to the different viewmodels

Dave

Hi Dave

Hmm yes that makes sense, treat IPublishedContentModelFactory as your repository Model and spin off as many ViewModels as necessary for your views. I've seen this demonstrated a lot recently in more "classic" MVC apps, rather than Umbraco projects.

If you need to include additional business logic do you still dump it all in the controller classes?

Martin

Thanks Dave for great example.

Martin, Controllers shouldn't contains a logic, I think better place is helper classes or BLL layer.

Hi Alex/Dave

In an umbraco context rather than a "standard" MVC application I think its a bit of a grey area because 99% of the time Umbraco is the R in CRUD as you're building out IPublishedContent in almost all cases. So almost all my "logic" is orientated around building out the HTML page. Initially I did most of this in my views, but then quickly realised this like going backwards in time to the days of classic ASP! aRRGggH! So now I try to do as much as possible in the controller and have built custom models along with a bit of route hijacking when I wanted to inject data from sources other than IPublishedContent in my views.

So to sum up from everything i've been reading (and through your excellent advice) by using something like ModelsBuilder, DI and Automapper I can create a something much closer to MVVM and (in theory) be able to tweak and test it much easier than I have been able to in the past.

Thanks very much for your advice! :-)

Martin

Yes, Martin, all logic in the controllers, except foreaches and other view logic.

Thanks Martin and Dave, very interesting topic!!!

is working on a reply...