C# Constructor and private LINQ to SQL members

Question

I am extending an application I have developed so that it is more broadly useful for multiple jobs, rather than the single job I created it for. There are a number of tables that I get from SQL Server with LINQ to SQL. Instead of having all records from the database populate the application, I want to filter first by job. Currently my viewmodels all have the same construction: a set of private ObservableCollections that get the data through the LINQ to SQL classes, a constructor that sets up binding commands (trying to practice good MVVM), and then the logic. So what I do now is something like this:

partial class MainViewModel : InotifyPropertyChanged
{
    ObservableJobs _oJob = new ObservableJobs(_dataDc);
    public MainViewModel()
    {
        NumRecords.Value = oJob.View.Count;
    }

    public ViewableCollection<Job> oJob
    {
        get { return _oJob; }
    }
    // and then the stuff that the viewmodel takes care of follows
}

public class ViewableCollection<T> : ObservableCollection<T>
{
    private ListCollectionView _View;
    public ListCollectionView View
    {
        get
        {
            if (_View == null)
            {
                _View = new ListCollectionView(this);
            }
            return _View;
        }
    }
}

It strikes me that _oJob is populated before the constructor is run, as the NumRecords.Value is assigned the actual records from the database. Is it better practice to declare outside the constructor and assign inside the constructor, or is it only a matter of timing/ sequencing when things happen? In my next phase I think I need to control the timing of when things get loaded better, so that I minimize the number of records transferred from the SQL Server.

If I try to declare it this way I get an exception, inner exception says "Value cannot be null. Parameter name source".

    ObservableJobs _oJob;// = new ObservableJobs(_dataDc);
    public MainViewModel()
    {
        _oJob = new ObservableJobs(_dataDc);
        NumRecords.Value = oJob.View.Count;
    }

How do I go about controlling how I instantiate the observable collections so that I can set a jobID (or pass one to the constructor along with the datacontext) and filter the querys?

Here is the ObservableJobs class:

class ObservableJobs: ViewableCollection<Job>
{
    public ObservableJobs(DocControlDC dataDc)
    {
        foreach (Job j in dataDc.Jobs)
        {
            this.Add(j);
        }
    }
}

Answer 1

Why not do DI instead of newing up the object right in that class? That way you don't have to bother about the original problem because it will be initialized for you and then be passed in.

Also it would make it much easier to test your view model.

But to answer your original question. In case you have to initialize inside of your class then I would say:

It is a matter of efficiency.

Here is the rule of thumb that I go by:

If the property being instantiated is going to be repeating in multiple constructors the same way then I just take it out and initialize it on the top. It is easier to see on the top when you are trying to understand the class as well (Or have a private constructor that rest of the overloads call as a part of initialization - this however creates unnecessary amount of duplicated code - having it on the top is just one liner).

If it is going to be initialized differently per constructor then I keep it inside of the constructor, which is self-explanatory.