I've found that Linq2Sql doesn't (Rhino) mock well, as the interfaces I need aren't there. Does EF generate code that's more mockable?
NOTE: I'm not mocking, yet, without interfaces, the next reader of this question may not have my bias.
EDIT: VS2008 / 3.5 for now.
Entity Framework 1.0 is mockable: http://blogs.msdn.com/diego/archive/2008/03/03/unit-testing-your-entity-framework-domain-classes.aspx
It's not pretty, but it's possible. EF 4 is much improved over EF 1.0 in this regard.
I would think that if, for example, you have Data Access Objects (DAOs) over your Linq2SQL objects they can implement intefaces and therefore work well with RhinoMocks.
Related
This is my first question on SO, so please bear with any mistakes/irregularities.
I wanted to implement SPA for my new project, Hence I reached Steve Sandersion's after some googling blog.
Looking at the code hosted on github, I noticed that I had to use EF to use Upshot, but my DAL is already written in Linq to Sql, which will be very tiresome to migrate to EF.
So my questions are as below
Has anyone successfully used upshot with L2S? If yes some example would help.
Is there any other way to implement the SPA without upshot so that I can reuse my DAL in L2S?
Edited
I just found today that this question stands useless, as using upshot will not be feasible. Microsoft has stopped working on Upshot.Some one please close this question.
I don't think it is possible. Microsoft has made it sure that people using Linq-to-sql don't survive.
Better use something like jquery and web api with some js mvvm libraries.
As far as I know this should be possible. When using upshot you don't need to use entity framework, you can do the wireing for your self.
In my ria 4 html demo, I make use of ria services to get the data from the server to the upshot client. This way it doesn't depend on the DAL you have. Ria services works by conventions, meaning insert, update and remove methods are present on every domaincontext and you can implement them as you want. For more info you can read this blogpost on setting everything up. And this on for the CRUD operations.
I'm thinking about moving from EF model first to code first. The advantages look clear enough to me and it seems quite intuitve to use.
What are the disadvantages compared to model first? What pitfalls must I suspect?
There is set of disadvantages:
You must write all code by yourselves
You have lesser control over database generation
You don't have support of Database power pack for incremental database development (code first have SQL migrations but they are still in beta and doesn't provide same feature set as power pack)
You will lose some basic and almost all advanced mapping features (but those advanced features are usually not used with model first anyway).
You will most probably use DbContext API
It will be new for you (unless you already use it with model first)
You will still have to revert to ObjectContext API in more complex cases because DbContext API is only for simplest tasks
It can have additional bugs and sometimes it has even worse performance than ObjectContext API
IMHO after several months of usage and following EF tags on SO I think it is still quite unmature
Anyway DbContext API is the mainstream. Since .NET 4.5 DbContext API will be Entity Framework and ObjectContext API will be Entity Framework Core libraries. It definitely means that DbContext API is what ADO.NET team wants to push forward.
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.
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.
What if you need to create POCO objects from a dbml file? Do you use a generator and who? You write the POCO's manually?
Say you like to make your objects Persistent Ignorant and share to clients, then create a DAO pattern for the communication between Client - DAO - L2S Objects, this is a question for disconnected design using Linq 2 SQL. Supposed that the POCO's using the client should be as much as primitive as they can be without dependencies (EntityRef<>, EntitySet<>, Attributes, etc.), and ofcourse you could cast the L2S object into the POCO with the appropriate DATA.
Any help and any corrections on the concept would be really helpful!
I would be tempted to say "wait until EF in .NET 4.0", which has much improved POCO support (compared to EF current) and hopefully a POCO T4 template in VS2010.
At the moment SqlMetal will emit rich objects; while LINQ-to-SQL can work on POCO types, you would have to write the POCOs yourself, or use xslt / T4 / whatever on the dbml.
SqlMetal can emit an XML mapping file from an input DBML file via the /map[:file] switch. This removes attributes from the generated class files, which is a step closer to POCO - you just have to remember to initialize your data context instances from the XML mapping file.
Removing EntitySet<T> and EntityRef<T> references is harder, and I'm not sure it's something I would recommend as you would lose a lot of useful functionality. However, it is possible - you need to manually manipulate the DBML file that you pass to SqlMetal by removing all <Association> elements. You could do this using LINQ to XML as a custom step in your build process, for example.
This would basically disable associations in the output mapping file and classes, as SqlMetal will only generate EntitySet / EntityRef code for <Association> mappings. You lose the ability to manage parent-child relationships automatically though.
That would give you a pretty close POCO pattern - the only other thing you would get is the INotifyPropertyChanging implementation, but I think you could justify hanging onto that as it is fairly generic.
If that doesn't meet your needs then you could look at doing your own code generation - check out T4 templates for LINQ to SQL which works in VS 2008 and is based on SqlMetal, but you have the option to totally customize the output to suit your needs as it uses T4 for template specification and output generation.
We also use Linq2Sql and need to write own model classes from L2S results. After lot of googling I've found T4 POCO Templates for Linq2Sql and EF which uses .dbml or .edmx files as a source and create own POCO entities.
Link to download at the bottom of the article or duplicated here.
We used it as a base and then customized it for our needs.