Vwwxrf

Honestly, I have been really trying to read up and learn the best techniques for uncoupling different portions of my applications.

I have such a long way to go in regards to this and entity framework 6. I was hoping to post this small sample and get some feedback as far as tightly coupling was concerned.

Preface: this application is something I am doing as a personal practice project that relates to theme parks and rides.

So, basically we first have one of the objects that represents something I would take out of the database. This class is as follows:

 public class Parks
 
 public int Id get; 
 public string ParkValue get; set; 
 public string ParkName get; set; 

 

Simple class, with 3 properties. Now here is the data access that builds this based on an Id which comes from a different portion of the application.

 public class ParkDataRetriever

 public Parks GetSelectedPark(Parks Park, int Id)
 
 using (var Db = new MyContext())
 
 List<ParkList> ListOfParks = Db.ParkLists.Where(x => x.ParkId == Id).ToList();

 foreach (var Parks in ListOfParks)
 
 Parks.ParkId = Park.Id;
 Parks.ParkName = Park.ParkName;
 Parks.DomValue = Park.DomValue;
 
 return Park;
 
 
 

Please look past the fact that the loop is somewhat pointless as we only return one ride, since it is not possible for this identity field to be duplicated. So that can be ignored right now.

So then in the application, we now have a type of class Parks that we can now use in the application. So I have two questions, is this an example of decoupled code from the data access perspective? So basically any of the data access I do, looks a lot like that GetSelectedXxxxx, not always filtering with Id, but similar anyway. Now granted, I'll never change the data storage of this small project, the project will never need to scale, and it will never need to be over engineered for what it is. The point is more educational. So I would want to treat this project as if it was large, enterprise scale, for the sake of the study.

Thanks guys!