I my last post, I described the benefits of applying the Repository pattern to encapsulate all logic pertaining to the direct manipulation of your data entities. The repository is responsible for shaping the data entities that will get passed back up through the ASL to your services or views, as well as pushing the data through the data services layer down to its final persistence location. You should note that this could be any number of data source types, from a relational database, to xml files, to an external web service. The repository is the manager of all such data centric interactions.
It is most important to note that when fetching data and passing it up into the application layers, it should be packaged appropriately based on the need of the calling layer. While you could simply pass full data entities of your Model into the application from repository calls, care should be taken to avoid unnecessarily exposing full Model entity details throughout your application. It is important to minimize the number of locations that will break if the data model changes over time, and rest assured, it will change over time. For this reason, we depend upon the ASL and Repository layer interfaces when using and accessing the Data Model as these methods can be used to create packages of data that represent just the specific information necessary to enact a Use Case or support a View. This collection of information is often referred to as the ViewModel; you can think of this as a Model specifically abstracted for the View, or a specialization of the domain Model.