Does anyone know how to have dependency injection work with linq2sql. Heres my situation..
I will explain it as best i can here.
I have a base class which has a DBML (linq2sql) and classes etc .. This DBML is COMMON to more than 1 project.. Well each project has its own DBML but has all the tables etc that is in the common dbml i am using in the base class - does that make sense?!
Each of my projects creates a new class by inheriting the base class and extending it... but of course i need to REINJECT my dbml because the dbml that i use specifically in my project has all the functionality that was in COMMON and then some
I am a little lost here.. Anyone know how to achieve this.. I do hope i explained it well enough :-)
I was hoping to use unity or something similar, the classes that are created by linq2sql don't seem to implement interfaces... is this going to be a issues with DI?
Thanks
It sounds like you probably don't need a DBML in every project. I would recommend having one project "MyCoolApp.Entities" that contains your Linq to SQL entities, and then reference that project in your other projects. Those other projects can extend your base entities as needed.
As for Dependency Injection, Unity can definitely resolve dependencies that don't implement interfaces so that shouldn't be a problem.
Related
I am trying to build a domain model with business methods and have EF 4.1 doing the persistence for me. So far so good.
Problem is, all properties are exposed as public on my domain classes. That's at least what I learnt from the tutorial anyway. That means, I have no strong proof that class properties won't change by some careless programmers outside of business methods. Encapsulation violated.
I tried introducing ISomething but TableAttribute applies only to classes, not interfaces, so I can't tell EF to do DBSet. If I leave TableAttribute to classes but make Something implement ISomething anyway then I can't do DBSet.Add() because EF doesn't know ISomething.
The only way I can think of is write a complete abstraction layer on top of EF 4.1 for CRUD using interfaces. Under the hood, do the type translation between Something and ISomething. It sounded a lot of complexity and a gaping hole in EF's design. Or I must've missed something.
How would you solve this?
Many thanks.
Problem is, all properties are exposed as public on my domain classes.
That's at least what I learnt from the tutorial anyway. That means, I
have no strong proof that class properties won't change by some
careless programmers outside of business methods. Encapsulation
violated.
How this will be solved by interface? Interface will again expose all properties as public and EF demands that property must have getter and setter.
EF is not able to work with interfaces. When using EDMX for mapping it is possible to play little bit with properties' accessibility but when using code first it is much worse because mapping is affected by the same accessibility rules. Creating abstraction layer on top of EF is mostly same as not using EF at all. Once you create abstraction you cannot use linq-to-entities directly and you will lose main reason for using EF.
Your problem is more about: Where is the boundary? If you want to work with entities only in business methods you should not expose them from these methods. If you want to make sure that properties are correctly handled perhaps you should implement validation logic directly into the entity.
Say "Foo" is a Linq to SQL entity created in the Linq to SQL designer.
I then have "Bar" which derives from "Foo".
Should I be able to save "Bar" using Linq to SQL (assuming I don't care abut saving any of the extra properties on Bar).
using (myDataContext ctx = new myDataContext())
{
ctx.Foos.InsertOnSubmit(instanceOfBar);
ctx.SubmitChanges();
}
Is this supposed to be supported?
Thanks much,
Jon
I've tried to do this once upon a time and couldn't get it to work. Can't remember what the error that was thrown, but to get around it, i basically had to go through all the properties using reflection and copy the properties marked with ColumnAttribute into a new base class instance and then insert that instead. It's not pretty, but it works. I haven't reinvestigated the issue since i implemented it, so if there's a better way, i'd love to know.
I'm not sure, but why are you doing it? The entities are all implemented as partial classes, so why don't you just implement what you want in a partial class?
I'm a stickler for the repository pattern which means that I define my models in an isolated dll (project.Models.dll) and then create a LinqToSql implementation of my IRepository.
The linq classes only exist within the LinqToSql implementation dll and I create extension methods to convert from my models to the linq entities and vice versa.
I've found that this enables you to test more parts of the system without being overly reliant on the database. It is a bit of a pain though, but you only do it once per project.
Which then means that you have full control over the serialization of your objects, and can do pretty much whatever you like with them
I tried out EF back in .NET 3.5 SP1, and I was one of the many who got frustrated and decided to learn LINQ to SQL instead. Now that I know EF is the "chosen" path forward, plus EF 4.0 has some exciting new features, I'd like to migrate my app to EF 4.0.
Can anyone suggest any good resources that are specifically targeted towards 4.0 and L2S migration? NOTE: I can find plenty of blogs and articles related to migrating from L2S to EF on .NET 3.5, but I feel like many of those were obviously dated and unhelpful to someone using 4.0.
I'd really like as much deep, under-the-hood stuff as I can get; I want to really come away feeling like I know EF 4.0 the way I currently know L2S 3.5.
TIA!
I have done loads of this very type of conversion and FWIW, I would say there are more similarities than differences. I don't think there is any definitive documentation that will make you feel like an expert in EF4, beyond the stuff that is already out there...
http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx
What I can give you are the more obvious "gotchas." Specifically, Linq2Sql wanted to combine the business layer and the data layer a lot more obviously. It really pushed you to create your own partial classes. I could go on and on about way, but the most specific reason is the way the one-to-one mapper will create public parent and child properties for all relations.
If you attempt to use any type of serialization against this model, you will like run into circular reference problems as a serializer moves from a parent to a child and then back to the parent as the Linq2Sql serialization behavior automatically includes all children in the graph. This can also be really annoying when you try to grab a customer record to check the "Name" property and automatically get all the related order records included in the graph. You can set these parent and child navigation properties to be either "public" or "internal" which means if you want access to them, but don't want the serializers to automatically create circular references, you pretty much have to access them in partial classes.
Once you start down the partial class path you generally just continue the pattern and eventually will start to add helper methods for accessing your data into your individual entity classes. Also, with the Linq2Sql DataContext being more lightweight, you often find people using some kind of Singleton pattern or Repository pattern for their context. You don't see this as much at all with EF 3.5 / 4.
So let's say you have some environment similar to the one described and you want to start converting. Well, you need to find out when your DataContext is going to be create/destroyed...some people will just start each Business Layer method with a using() statement and let the context pretty much live for the lifetime of the method. Obviously this means you can get into some hairy situations that require adding .ToList() or some other extension method to the ends of your questions you can have a fully in-memory collection of your objects to pass to a child method or whatever and even then you can have problems with attempting to update entities on a context that they weren't originally retrieved from.
You'll also need to figure out how to much of the BusinessLogic incorporated in your Linq2Sql partial classes out into another layer if it doesn't deal explicitly with the data operations. This will not be painless as you figure out when you need/don't need your context, but it is for the best..
Next, you will want to deal with the object graph situation. Because of the difference in the way lazy-loading works (they made this configurable in EF 4.0 to make it behave more like Linq2Sql for those who wanted it) you will probably need to check any implied uses of child objects in the graph from your Linq2Sql implementation and verify that it doesn't now require an explicit .Include() or a .Load() to get the child objects in the graph.
Finally, you will need to decide on a serialization solution in general. By default, the DataContracts and DataMember attributes that are generated as part of an EF model work great with WCF, but not at all great with the XmlSerializer used for things like old .asmx WebServices. Even in this circumstance you might be able to get away with it if you never need to serialize child objects over the wire. Since that usually isn't the case, you are going to want to move to WCF if you have a more SOA, which will add a whole new host of opportunies, yet headaches.
In order to deal with the partial classes situation, and the hefty DataContext and even the serialization issues, there are a number of new code-generation templates available with EF 4.0. The POCO-Entity template has a lot of people excited as it creates POCO classes, just as you'd expect (the trouble is that excludes any class or member attributes for WCF etc etc). Also, the Self-Tracking Entities model pretty much solves the context issue, because you can pass your entities around and let them remember when and how they were updated, so you can create/dispose your contexts much more freely (like Linq2Sql). As another bonus, this template is the go-to template for WCF or anything that builds on WCF like RIA Services or WCF Data Services, so they have the [DataContract], [DataMember], and [KnownType] attributes already figured out.
Here is a link to the POCO template (not included out of the box):
(EDIT: I cannot post two hyperlinks, so just visit the visualstudio gallery website and search for "ADO.NET C# POCO Entity Generator")
Be sure to read the link on the ADO.net team blog about implementing this. You might like the bit about splitting your context and your entities into separate projects/assemblies if you fall into the WebService vs. WCF Service category. The "Add Service Reference..." proxy generation doesn't do namespaces the same way "Add Web Reference..." used to, so you might like to actually reference your entity class assembly in your client app so you can "exclude types from reference libraries" or whatever on your service references so you don't get a lot of ambiguous references from multiple services which use the same EF model and expose those entities...
I know this is long and rambling, but these little gotchas were waaay more of an issue for me than remembering to use context.EntityCollection.AddObject() instead of context.EntityCollection.InsertOnSubmit() and context.SaveChanges() instead of context.SubmitChanges()...
For EF Code First, it's mostly about reverse engineering the existing tables into EF classes. EF Power Tools now does this for you:
http://msdn.microsoft.com/en-us/data/jj200620.aspx
The rest is the obvious work of modifying your existing code to use those generated classes to talk to the database instead of LINQ to SQL.
I am creating a website and using Linq to SQl as a data access layer, and i am willing to make the website can work on both linq to sql and ado entity framework, without changing many things in the other layers: business logic layer or UI layer,
Whats the recommended pattern to achieve this goal? can you explain in brief how to do that?
UPDATE
As answered below that repository pattern will help me a lot,
i checked nerd dinner website and understood it, but i found this code inside:
public class DinnersController : Controller {
IDinnerRepository dinnerRepository;
//
// Dependency Injection enabled constructors
public DinnersController()
: this(new DinnerRepository()) {
}
public DinnersController(IDinnerRepository repository) {
dinnerRepository = repository;
}
Which means as i understood that it declare a dinnerRepository using the interface IDinnerRepository , and in the constructor gave it the DinnerRepository, which will be in my case for example the linq to sql implementation,
My question is if i need to switch to ado.net entity framework, i will need to edit this constructor line or there is a better solution for this?
Update 2
Where should i put this Respository Interface and the classes which implement it in my solution, in the data access layer or in the business layer?
The Repository pattern is a good choice. If you implement it as an interface; then you can change out the concrete classes and not have to change anything else.
The Nerd Dinner walkthrough has an excellent example of the Repository pattern (with interface).
The code you listed there would go in your controller (if you were doing an MVC Application); and you create any class you wanted so long as it implemented the IDinnerRepository interface (or you could have something like an IRepository interface if you wanted to design an interface that everyone had to implement that did the basic CRUD actions, and then implement specific interfaces if you needed more (but let's not go interface crazy).
If you're 'tiering' your application, then that part would go in the "Business Logic" layer, and the Repository would be in the "Data Access Layer". That constructor contract would be the 'loosely' coupled part.
I wound up using a minor variation on the "Repository" pattern. I picked it up from the excellent Nerd Dinner tutorial. You can find the whole tutorial here and the code is on Codeplex.
Don't let all the MVC put you off if your not in an MVC situation, the underlying encapsulation of Linq2SQL is a good one. In a recent update of a codebase I went from Linq2SQL to Linkq2EF and all the changes were nicely dealt with in the repository, no outside code had to be touched.
It is also worth noting that the RIA Services stuff comes with a similar pattern. You point it at Linq2Sql or Linq2EF and it build you a basic layer over it complete with CRUD. That layer is in source code so you could just rip it out and use it in a non RIA project but I just leave it as is and link to it in other projects so I use the layer even if I ignore the over-the-wire abilities.
I'm trying to find a way to generate Linq to SQL classes with bi-directional serialization attributes. Basically I want a DataMember tag (with an appropriate order) on every association property, not just the ones where the class is the primary key (like the Visual Studio generator and SQL Metal do). I checked MyGeneration, but didn't really find anything that worked for me. I thought the T4 Toolbox was going to be my solution, it would be quite easy to modify it to add the attributes, but I get an exception on the calling side of my WCF service, and I've gotten no response back on the issue. I'm about to try installing CodeSmith and using PLINQO, but I'd prefer something free.
I'm pretty close to just writing my own T4 generator, but before I do that, I was hoping to find an pre-built solution to this rather simple problem first.
I ended up writing my own code generator for our L2S classes. We actually generate two sets of classes. One is a "lightweight" set of entities for client application use. These classes have no L2S plumbing. But they have the full datamember attributes with proper order. Then we have our L2S entities, which are strictly for backend use. This has worked out quite well.
Be careful using PLINQO. I've looked at that product extensively. In fact, much of my code generator is based on the code PLINQO generates. However, they have a "major flaw" (their words) in how they have implemented many to many relationships.
You might want to also look at a product named "Reegenerator".
Randy
This turned out to be the solution to my problem. I had just resigned myself to start researching my own generator when I stumbled upon that. It has a bidirectional serialization option and it works great! Here's a link to the author's bog, which contains a great video example of how to get started.