It sounds like you're struggling with :
- Maintaining a "rich" UI
- Doing most of your interactions via AJAX to the controller
- Keeping the front-end in sync with results of AJAX actions
If I've understood your issue correctly, you may want want to check out KnockoutJS, which is a javascript framework built for handling just these kind of scenarios. Take yourself through the interactive tutorial examples, it'll build the concepts you need slowly and logically. Quite a nice framework.
The pattern I have settled on for creating my view models is SomeViewModel is created by a static method (or instance method if appropriate) on SomeViewModelFactory. I don't inherit from base models for members that are duplicated. I use interfaces and external setter methods that operate on those interfaces to set the properties. This abstracts away the creation of the view model to a single function call for a single view model and one setter function called internally for each interface the view model implements. As you can tell, I prefer composition over inheritance in this case. To me, it is less complex and more reusable than inheritance.
You might be interested in Automapper if you are doing any mapping between your domain model for your database and your view models. Hope this helps spur on any ideas that may be laying dormant in your mind.
Edit: I forgot to mention that you can define extension methods on those interfaces to take inputs and do the setting on the object its self. This technique is called a "mixin". That way you don't need to create classes for your setter methods, they appear to you as instance methods on the viewmodel object.
Edit 2: To answer your first comment, that is up to you and your preferences. Personally, I like to stay consistent and I would just copy/paste the model into a new class and add the property. Then use the setter for the old class and just set that one property normally. Remember that there should be no logic in your view models; they should only know that they are holding data, not how that data is created.
Automapper is still being actively developed as far as I can tell. It's really more of a utility library rather than a full blown framework. It seems to be pretty mature to me, I've been using it at work with much success. You may have to write the code that goes from ViewModel to DomainModel for stuff like updating data in a database, but at least you won't have to do the DomainModel > ViewModel part. Automapper takes care of that very well.
Edit 3: Your concern about staying DRY is valid; however, I interpret that principle as don't repeat your logic (not data structure). Your view model is a support structure for your data that provides you the benefit of static typing in your view. Each view model is specific to a single view. Using inheritance for property reuse needlessly ties the view model of 2 separate views that just happen to be similar. If you use inheritance, changing the base view model has a ripple effect across all your views with view models that inherit from it. Maybe that is what you want, but you can get the same benefit by defining an interface for all view models that need it. If there is a change, this allows you to decide for each model if it should still implement that interface or if a new interface is needed.
Best Answer
if the scripts and styles that used in view1, will not be used in another views, the best way is to bundle them only at view1, but if they are common scripts and styles that will be used in many views, bundle them at layout.