You are currently viewing the BOOK: ASP.NET 3.5 Enterprise Application Development with Visual Studio 2008: Problem Design Solutio section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
I just got your book a couple of days ago and I really like how everything engages with each other. However I have a question concerning the DataContext in the DAL.
Though I'm still in chapter 4 I assume that sooner or later you will add every table in your database to the HRPaidTimeOffDataContext. Creating classes like ENTUserAccountData for every table ensures that every entity object knows how to insert, update or delete itself in the database. So far so god.
My problem is that all code in the DAL classes is using ONE DataContext (HRPaidTimeOffDataContext). What if your application would have more than one DataContext class?
Here is a scenario why I'm interested in that: Imagine you had two different customers who would both want to use your application. Instead of setting up two separate platforms (2 applications + 2 databases) you want to be smart and have rather one application for both of them. You would set up two databases though, one for each customer. The two databases would be pretty similar but not equal, because every customer has his special requirements. In the end you would probably have at least two DataContext classes like "EverybodysDataContext" and "CustomerSpecificDataContext". The tables that both customers have in common go in the EverybodysDataContext, the other tables go in the CustomerSpecificDataContext. Now that you have two or more DataContexts you would still want that any ENTBaseData object knows how to handle the CRUD operations, right? But the declaration of the ENTBaseData class refers to one concrete DataContext.
Do you see any way to have the type of DataContext being dynamic in your base classes? In other words: no matter how many DataContexts my application would have, all my entites could still inherit from ENTBaseData.
I realize this can not be answered with a simple Yes or No. And in case I didn't simplify the problem enough, please feel free to ask. But I would appreciate any suggestion you had for me.
Great question. What you can do is modify the ENTBaseData class so the DataContext is a generic parameter.
where T : IENTBaseEntity where DC: DataContext, new()
publicabstract T Select(int id);
publicabstractvoid Delete(DC db, int id);
publicvoid Delete(string connectionString, int id)
using (DC db = new DC(connectionString))
Replace any instance of the HRPaidTimeOffDataContext in the base class with DC. Then when you define the inheriting data classes you simply tell the compiler which DataContext to use.
Hey Vince, do you know if linq to sql has been implemted on a large scale. I will be working with 100's of sql tables and lots of relationships and to create an entity for each table seems like a lot of work. Just curious, I'm from the old school of using stored proc and no user ever has access to the table objects.
Please excuse me, but I'm also new to linq to sql so maybe I just need more time to learn it. However I do link the fact that I can drop in the stored procs.
I use it on large scale databases but I create multiple data contexts for "groups" of tables. I try to group the tables together by department or something that makes sense. This makes it easier to have multiple developers working on one project especially when using sourcesafe.
If you prefer not to use LINQ to SQL you can always pass the data between the DAL and BLL with datareaders. Everything else in the pattern will still work, you'll just need to make some changes in the bases classes and the BLL classes that reference the entity object. This is how I used to do it before LINQ to SQL. I'm now changing it againg to work with the Entity Framework.
Yes I know, please read my question carefully I did the same with the business classes EO objects then when I got the BaseEditPage which uses ENTBaseEO I get stuck; my ENTBaseEO is also a generic type ENBaseEO(Of DC as DataContext..) as it uses DC for
save update etc.. The reason I get stuck is I am reluctant to specify a datacontext in the BaseEditPage class for several reasons 1- the UI should not talk to the DAL, 2- the BaseEditPage class is used by many inheriting pages and cannot be datacontext specific.
And also in your response above Using db as new DC(connectionString) vb.net does not seem to accept the connection string parameter.
Last edited by luckystar; May 14th, 2009 at 04:59 AM.