I used to use Visual Studio Class Diagram in ~2012 (VS Studio enterprise at that time) but it seems that it doesn't quite evolve since then?
Class diagram reverse engineering does not detect any relation with ObservableCollection and does not detect it when I try to add a simple Association manually where there is a generic derived class with an IEnumerable.
EF Core can detects all those relations properly. Does Class Diagram can do it? Do I miss something?
Does anyody know if there is an existing fix for that?
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'm new to Linq and Visual web developer 2008 Express. I have read some posts here and Scott Guthrie's on setting up Linq, but I'm a little stuck because the classes aren't auto-generating as I thought they would. I have setup a database with a simple table (with the Primary Key as the ID, and it is set to auto-increment) plus a few other columns, and dragged and dropped it on to the DBML Linq designer pane. The table appears in the window, but no classes are auto-generated. When I right click on the table and select "View Code", DataClasses.cs is displayed, but I only see a partial class with no methods or properties.
Isn't Linq supposed to do this, or have I (quite likely) missed the point completely? Or is this functionality not available in Visual Web Developer 2008 Express?
No, you're not missing anything. That is exactly how it should work. Go to solution explorer, expand the dbml, and double-click on whatever.designer.cs. Down at the bottom, you'll see ...
[Table(Name="dbo.YourTable")]
public partial class YourTable: INotifyPropertyChanging, INotifyPropertyChanged
{
private static PropertyChangingEventArgs emptyChangingEventArgs = new PropertyChangingEventArgs(String.Empty);
... and all of your properties.
As the other answerers have already pointed out, you do get your code generated - into a single (modelname).designer.cs file.
This may or may not be what you expected and wanted - if you can live with it - perfect!
If not, there's at least one set of Code generation templates out there called PLINQO which are based on CodeSmith, the well known code generator. Those templates allow you to do a lot of things standard Linq-to-SQL doesn't support:
generate classes for each table into their own, single file in a user-definable folder
actually update your DBML model and all associated generated classes if the underlying database changes
adds a "(entityname)Manager" class to manage entities of a given type (like Customer etc.)
All in all, it's quite a neat solution to handle Linq-to-SQL code generation. Excellent stuff - recommended!
Marc
As mentioned, LINQ-To-SQL will not actually generate individual class files for you - if you go and write some code that references a class for one of your tables, you will find that it is there...
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.