Do I need to call Tolist() methods for these layers?

Sep 18, 2012 at 9:48 PM
Edited Sep 19, 2012 at 2:03 AM

Hi,

1. I have Data Access layer

public virtual IEnumerable<DiningTable> Execute()
        {
            return this.GetDbSet<FloorPlan>().ToList();

        }

2.This is belong to Domain layer
public virtual IEnumerable<DiningTable> Execute()

        {
            try
            {
                return this.entityRepository.GetTableByFloor();                //Shall I call tolist at this layer.
            }
        }

3. My ViewModel

public ListCollectionView listingDataView { get { return this.Using<GetTableForFloor>().Execute(); } }

//Shall I call tolist at the viewmodel

This is ralated to WPF but I following your pattern so that no reason to post it at WPF forums

There's 3 layers.

1.ViewModel

2.Domain

3.DAL(EF)

Developer
Sep 19, 2012 at 2:33 PM

Hi,

Based on my understanding the decision on where to call the ToList() method will be related to a design choice you will have to make for your scenario.

A common approach is to call this method in the Data Access Layer, as this is useful if you want to ensure that the query is executed in this layer (e.g. in your Repository implementation). As explained in Chapter 11: Server-Side Implementation from the Silk's documentation, if ToList() was not called in this layer, then the repository would return an IQueryable<T> and the database would not be accessed until something iterated over the IQueryable<T> object. The problem with returning an IQueryable<T> is that a developer consuming the API is likely to assume that the query has already executed and that you are working with the results. Causing that if you iterate over the query more than once, it will result in multiple calls to the database.

As an example of this approach you could check the MileageStats’ FillupRepository and ReminderRepository implementation. Once again note that which approach you take will depend on your personal decisions.

Also, regarding this topic, I believe you could find the following thread from the MSDN forums interesting:

I hope you find this handy,

Agustin Adami
http://blogs.southworks.net/aadami

Sep 20, 2012 at 8:03 AM
Edited Sep 20, 2012 at 8:37 AM

Hi aadami,

Again, As I said this is relate to WPF but I employ your pattern. I wonder about MVVM plus new EF and because of there's no MVVM plus EF pattern form Microsoft.

My meantion are the MVVM plus EF doesn't clear enought from Micosoft. I could not got any ideas from WPF forums. I don't want to post this again at WPF forum.

1. Q If we call the helper mothods.

 

1.1  Using<GetData1>()

1.2  Using<GetData2>()

 As you can see there's 2 of Using<T>(Actually more with real work) above. If I execute the commnads twice or more. Are we invoke the same DbContext and query the same data or Invoke new instance of DbContext, each time when we execute?

2. Q

the Entities's state lives at Data Access layer. These are the entities's states 1.Added, 2.Modified, 3.Deleted, 4.Detached

How do I track these stats at ViewModels?

 

How do I track these entities at ViewModels? when underlying data get changed then reflect UI to update or INotityPropertyChanged.

As you know we have 2 layer separate between DAL and BLL.

 

Could yu give me some suggustion how to archive this kind of pattern?

Please...My the teacher and you re really good teacher.

Best Regards,

Weera

Developer
Sep 20, 2012 at 6:54 PM

Hi Weera,

Regarding the call to the helpers methods you mentioned, take into account that these methods are used to delegate logic and as far as I know which behavior you will obtain when calling them, will depend on the particular logic they execute. In other words as mentioned above, this will depend on your design choices and on how you implemented your Data Access Layer, as those considerations are also valid for WPF applications.

On the other hand regarding how to track the entities from your view models, I believe a possible approach to achieve this could be for example to consume a service from your view models, which could wrap your Repository implementation and contain the necessary logic to keep track of these entities and their corresponding changes. For example this service could expose the necessary properties and also raise events when those properties are changed.

As a possible example of this approach, I recommend you to check the Stock Trader Reference Implementation provided with Prism. Although it does not use the Entity Framework, this should not be a problem as your view models should not depend on your data retrieval mechanism.

I hope you find this useful,

Agustin Adami
http://blogs.southworks.net/aadami