Attention: We have retired the ASP.NET Community Blogs. Learn more >

BLL With LINQ

Hello,
 

I am currently working on a little project I call GeekTube, it is going to be an internal repository for videos. Implementing my BLL has never been easier. My approach has been to implement all my static helpers as part of a partial class. For example:

partial class Video {

        public static Video GetVideo(GeekTubeDataContext db, long ID) {
            Video vid = db.Videos.FirstOrDefault(p => p.ID == ID);

            return vid;
        }

        public static IEnumerable<Video> GetVideos(GeekTubeDataContext db) {
            var videos = (from video in db.Videos                         
                          select video);

            return videos;
        }

        public static IEnumerable<Video> GetVideosInCategory(GeekTubeDataContext db, long CategoryID) {

            var videos = (from video in db.Videos
                          where video.CategoryID == CategoryID
                          select video);

            return videos;
         }    

        *** SNIP ***

}

Then from the frontend simply use something like:

GeekTubeDataContext db = new GeekTubeDataContext();
var videos = Video.GetVideos(db);


With the GetVideosInCategory method. This maybe should be done by loading a category and getting its videos via the realationship, i.e.:

var videos = Category.GetCategory(db, 1).Videos;

But this runs two SQL queries one to load the category and the other that loads the videos. This is find in a case when I will use both but sometimes I may only want to get the videos so the need for the extra method.






Anyone with an oppinion on better ways to do this with LINQ would be good. Look forward to posting more useful information as I progress more with the project.

 
Cheers

Stefan
 

8 Comments

  • You might save more code if you make datacontext as part of class

  • Thanks,

    Only reason I keep datacontext external as on the frontend site I have a Util.GetDataContext() method which returns an instance of a datacontext but it fills in the connection string from my front end web apps web.config.


    Stefan

  • Hi.

    &gt;fills in the connection string from my front end web apps web.config

    You might do the same from the inside of you'r bll object.

    The only one thing that might be the reason for using external DataContext object if you use the same object from different DataContexts, which is very rare case.

  • The designer for LINQ to SQL doesnt seem to let you map the connection string to the web.config very nicely. I found that you can howerver edit your .dbml mapping file with the xml editor and add the following element and it will generate a default ctor for you that gets the connection string from the section of the web.config.

  • Cheers for the tip...

  • Actually, it seems to demostrate how ymplementing your BLL has never been unnecessary.

    What exactly is the advantage of

    int someID = 123;
    GeekTubeDataContext db = new GeekTubeDataContext();
    Video video = Video.GetVideo(db, someID);

    over

    int someID = 123;
    GeekTubeDataContext db = new GeekTubeDataContext();
    Video video = db.Videos.FirstOrDefault(p => p.ID == someID);

    How is the format any "less coupled"? --- Both sides need knowledge of the GeekTubeDataContext & Video classes. Are you expecting the query for selecting a video record by id to change in the future? -- If so, we could isolate just that part:

    Predictate SelectById(int ID)
    {
    return ( (Video p) => ( p=>p.ID == ID) );
    }

    int someID = 123;
    GeekTubeDataContext db = new GeekTubeDataContext();
    Video video = db.Videos.FirstOrDefault(SelectByID(someID));


    The main problem which the separate BLL is as you discovered with your GetVideosInCategory method : You either have a few basic methods (which leads to inefficent code) and many very specific methods (and when a method is only called from one place, it's becomes pointless as a separate method).

    (note further with the additional problem with the "few basic methods" method. By writing:

    var videos = Category.GetCategory(db, 1).Videos

    You are already moving part of you data access into you appliation code. So you still have the problem you were trying to avoid, and made it even worse, by splitting the logic between two modules.





  • Yeah thanks some very good points there. It is hard to work out how we should be using this properly. I would like to seperate data access logic from UI but unless I write lots of helper methods acheiving this is a pain. Or I use half and half as you say and make life worse. I just dont like the idea of writing my LINQ queries in the UI layer.

    Might have to revisit how I am going to tackle this.


    Cheers

  • mmm still not sure after thinking of the many specific methods approach a little more, it doesnt seem to be such a bad idea. So would use GetVideosForCategory, GetVideosForTag, GetVideosWithKeywords etc... The only other reason for using the DataContext in the frond end is so I can then bind to say a linq data source with paging and it would then take that query and only hit the database for the required results.

    This could also be seen as bad as the front end is now doing data access again. GRRRRRR going around in circles here.

Comments have been disabled for this content.