Is it or will it be possible to override the internals of the DataContext
I want to alter the object creation implementation in the datacontext to create subclass proxies instead of just instancing the entity types directly.
However DataContext seems very black boxish.
Im well aware of the claims that non virtuals execute faster than virtual methods etc.. but in this kind of scenario where big chunks of data is fetched from some sort of datasource , those few nano seconds will be impossible to notice.. so that will hardly be a valid argument.
Ive seen that there is a "services" collection inside the datacontext , but that also seems impossible to access from the outside.
it would be really really lovely if such things were exposed so that we could extend things to our own needs.
My idea is to use our framework NAspect to apply property interceptors and notification mixins to the entities.
so that it would be possible to create entities w/o implementing the tedious and cluttering code for change/inverse notifications and object initializations.
this would allow the DLinq entities to be more POCO while still beeing able to use those featrues.
Also, please make more interfaces in .net :-)
a IDataContext interface would be nice , so that if we want , could just swap out the entire core logic and still let standard dlinq entities interact with our totally custom datacontext.
//Roger
www.puzzleframework.com
Extending DataContext?
James_AeroAvi
exactly,
can some one on the dlinq team verify if there are any plans to let us plug the services inside the datacontext
//Roger
edhampt
Don't confuse a frustrating habit for a bad habit.
There are good reasons to seal and make things internal. For example, it reduces the exposed surface area which makes things easier to test. These are also places that could be exposed later; premature exposure means we live with the consequences forever.
Consider it a form of risk management: we manage the risk of users using APIs that may not be as well tested as other, public APIs, and we manage the risk of creating a bad API before thinking it through (and seeing what people come up with as alternatives).
That said...
The idea of calling a web service is indeed an interesting one, if that's what you're suggesting. But it may not actually have anything to do with LINQ to SQL beyond the idea of materializing the results on the client end. I think it's more of a "How do I translate an expression tree into a SOAP (eg, WCF) call ", which isn't much in the way of SQL. To that end, Fabrice has an example that calls Amazon's web service.
vcspec
We have no current plans to allow you to modify the services inside DLinq, however we are still finalizing the notification/eventing system so keep the suggestions coming.
As far as object creation goes, this is handled by the provider. In fact, most aspects of DLinq are actually handled by the provider. DLinq services offer only identity management, change tracking and update ordering. Everything else is the provider. Still the possibility of overriding the creation of new instances is interesting.
garyl
CodeWarrior1
The best of all is if we ( developers) are asking for it, is because we like the DLink and QLink idea and would like to change for us needs.
"what I suggest is that instead of blackboxing everything, make some parts open."
I think that in March CTP DataContext will more "open".
Regards,
Alexnaldo Santos
Gabe J
No that was not what I suggested, that was an example of when it would be good to be able to hook into the datacontext.
what I suggest is that instead of blackboxing everything, make some parts open.
Eg, object creation, there are some hokus pokus methods insude the datacontext that are responsible for creating the objects that are supposed to be returned.
why not make a factory for that
eg:
protected virtual T CreateObject<T>(...) : where...
{
return new T();
}
with such approach(or an event based one) people could hook into the object creation part and do what they want.
eg, create an instance of some sort of runtime subclass.
The problem I have with ms frameworks is that they are a blit like "ok if you use this framework you can not use it together with anything else because that wont work, take it or leave it"
I want to be able to use DLinq and I want to be able to use eg our own NAspect framework that relies on runtime subclassing.
there is so little effort from MS side to make such extensions possible, yet , they never do it, they ignore common designpatterns like factories.
and that is really frustrating since such approach would be non intrusive on their design.
"Consider it a form of risk management: we manage the risk of users using APIs that may not be as well tested as other, public APIs, and we manage the risk of creating a bad API before thinking it through (and seeing what people come up with as alternatives)."
Yes but in what way does it matter if the api is good or bad if we _never_ get to use the api at all
Id rather take a extensible bad api over a good api that is blackboxed out of my reach.
//Roger
Tuoski
I won't object to any interfaces, ITable<T> would be grand, but even more interesting might be an IDataContext interface.
Linq already has the potential to become the Great Unifier for the query languages - IDataContext could be really nice in providing a standard .NET API for non-query interfacing with a mapper.
//creates a DLinq DataContext or an IDataContext implementation from some other mapper
System.Data.IDataContext ctx = MyContextFactory.Create();
//do some stuff...
ctx.Commit() ;
...would be sooo sweet! :-)
/Mats Helander
Pivinski
Some of the notification you want may already be in place with DLINQ. You would just add your own custom handlers to the notification process. Re-reading your request in relation to NAspect, It appears you are requesting to eliminate the need for the notification code in each property Set and rather have the NAspect, or other similar framework handle that for you. Sounds like an interesting proposition.
As for extending the DataContext, I suspect at least some of the functionality you are requesting will be included in the forthcoming provider model.
I can understand your request for the interfaces. Currently we are tied in to the generic Table as the collection entity, whereas it would be helpful for that to be exposed as an interface or base type that we could build our custom collection objects on top of (similar to CollectionBase).
Jim Wooley
http://devauthority.com/blogs/jwooley/archive/category/1150.aspx
MatthewVincent
>>In fact, most aspects of DLinq are actually handled by the provider
So any chance that the provider classes will be not sealed and have virtual methods :-)
MS has a really bad habit of sealing and blackboxing their code so that if you need the slightest modification , you either have to hack with reflection or roll your completely own version.
Lets say for example that I want to create a soap remoting facility for the sql server provider.
eg that I want to override the part where dlinq sends the sql to the DB and instead pack the sql into some secure package , and send it over http somewhere and then deserialize some result into a IDataReader for object deserialization.
(ok I know that the example was a bit simplistic and might not just involve that little changes ;-) )
But will it be possible to do such things
So basicly there are two requests.
* Make the involved classes open for extensions through inheritance.
* Make the classes rely on dependency injection (setter or ctor) rather than be self configurating.
//Roger
V&#237;tor Ferreira
"Id rather take a extensible bad api over a good api that is blackboxed out of my reach."
That may be, but it's very difficult, if not impossible, to undo bad APIs -- at least, when you're having to support everyone that decides to make use of them. It is, however, much easier to extend and API after it's been thought out.
This doesn't say the suggestion is without merit -- quite the opposite (as Matt said, the idea of customizing object creation is interesting). What it does say is that there's an obvious need to investigate the various ways to solve the problem that led to the suggestion in the first place.
My frustrating moment, for your amusement: at my last employer, I was trying to make a drop-in single-signon system in ASP.NET, which was usable by non-.NET platforms, before I moved to Microsoft. It turns out that the login redirection wouldn't use the full URL, which meant that if the login page were on the different machine, things broke. Since the type was sealed, I had to re-implement a lot of code -- most of the authentication framework -- to make it work. Yes, I agree -- very frustrating when all I would normally have to do would be to override the specific method.
Now, would unsealing have been the right answer Perhaps, but that dramatically increases the testing burden (since now you have to deal with user-written classes that may not behave correctly). How about fixing the bug Great choice, but may break existing apps that depend on the broken behavior (like the armymen.exe hack). An isolated extensibility point Ah, now you can support both legacy and new apps, and you've only increased the testing area slightly.