how to modify collection classes provided by EF after associating one class to another? - asp.net-mvc-3

I'm new to MVC & EF. I'm developing the MVC project with model first approach. In my project i have different entities like-customer,employee,product,etc. and i created association between them like 1 to many in customer-employee like this. and after creating this association; it is generating navigation property in customer entity i.e, Employees (collection object) for employee entity.
I want to modify this collection class and i want to add some more methods on it. Is it possible? How to do this if possible?
thanks.

The property is generated with ICollection<Employee> type. You can in theory create your own class implementing this interface and initialize the property for example in Employee constructor but the property will still expose the interface. Changing return type of the property requires change in class generator (you should use T4 template which would make this easy task). By changing property's return type to your collection you can lose some EF functionality.

Related

Entity Framework: Implement interface when generating from database

I'm having a few tables on SQL Server, which have similar structure - int Id and string Value.
This tables linked to main table via foreign key, so I'm wrote a bit of logic for mapping a string values to id's in models in MVC Razor. This feature requires that models used as dictionary implement simple IKeyValue interface with Id and Value, but after updating model from database I can loose interface implementation from models and must write it again.
Any way to automate this?
Are you modifying the auto-generated file? If so, you should not do this, for the exact reason you describe in your question -- it will get overwritten.
All of the classes in the generated file should be partial. You can take advantage of this by creating another class (in a different file, but in the same project), make sure it has the same declaration (and namespace), and have it implement the interface. This way the class will implement the interface, but will not be overwritten the next time you refresh the schema from the database.

linq to sql, how to define DataContext without specifying Table properties

My intent is to create a generic (not in C# meaning) database model for Windows Phone using linq to sql. User of such model should be able to pass an array of his data object types (classes marked with Table attribute) to model's contstructor, and then model should take care about adding related tables to database and provide API for CRUD operations.
But then I've found out that in order to add tables to database, your data context (class inherited from DataContext class) have to declare each table as a property! That's embarrassing. Does this fact mean that my idea is not implementable? Because I obviously cannot add properties to my DataContext-based in the runtime.
So my question is, am I right in my judgments? If yes, are there some workarounds to solve this issue?
Thanks in advance.
EDIT: better question tagging, for somebody finally notice this.
You do not need to use a strongly typed DataContext (a class inheriting from DataContext and declaring properties for each table). You can do something like the following instead
var context = new DataContext("connection string", new AttributeMappingSource());
var table = context.GetTable<T>();
where T is some type marked with the Table attribute.

DDD model to EF

I have two questions.
1: At the moment I have two model classes that are mapped to two entities in the EF diagram.
How does DDD work with EF because if I decide to split my model classes into smaller specific classes e.g. from 2 to 4. How will EF relate to them?
Will I have to create a seperate DTO to map these four model classes to the two entity models that EF will understand?
Just wondering how other people have managed to get around this issue.
2: EF only recognises models that have public properties. If I change my model class to have behavioural methods like GetName(), SetName(), GetAddress() etc and remove the public properties to be private members then EF throws a wobbly and complains it can not find any properties on my model.
How do I solve this issue? Or would the answer be the same as the first question in that I need to create a DTO that has public properties which map from my model class which EF will use?
I'm just thinking if this is the correct path to take because it seems like a bit of redundant work having to map my DDD model classes to another set of DTO or EF model classes that EF understand.
If I do have to map to the EF classes will they be in the model layer or repository layer?
There are possibilities to map multiple entities to the same table (TPH inheritance, table splitting) but these possibilities must follow strict rules. Otherwise you could end up with scenario where you cannot insert entity to database because it doesn't contain all required columns for the record.
EF (with EDMX) recognizes non public properties as well - EF code fist requires at least property with accessible getter or setter. Moreover those behavioral methods can be redundant because writing your own getter and setter in property has the same meaning.

Custom Collection extends List<T> Add method

I want to create a custom collection and add my own custom Add method.
Scenario:
Teacher.Students.Add(Student s)
I want to put LINQ methods to save the teacher/student relationship to the database, not just add it to the list.
How can I do that? How can I know what "Teacher" object this is?
Your best bet is to set up and configure an ORM (Object-relational mapping), such as NHibernate, that will manage this for you. In effect, you set up the data model, and the ORM framework will take care of persisting that information for you.

Creating custom class for every Stored Procedure using linq to SQL?

I'm using stored procedure in LINQ, i know it will generate a class T(procedure name + "Result") for me automatically to store the data.
If the name of stored procedure is spCampus, the generated class will be spCampusResult.
My Question:
when i'm using SP should i create custom class that replicate all the properties ( i'm refering to whatever the .dbml creates when you drag and drop the SP)
in my situation i will be using SP... is that fair to say i will be treating as a class object and pass around from model to controller and to view ?
or i will be better off creating a new custom business object contining all the props from .dbml ?
i havent get any clear cut answer
anybody?
In the designer you can shape the object any way you see fit. You can change the names of the properties you can change the name of the object returned from the sproc if you want to. It is also my understanding that you can change the protection levels on the properties as well. This to me means that you can use the LINQ2SQL generated objects as your DTO's or you business objects because you have the power to shape them as you see fit in the designer and since they are partial classes you can extend their behavior without touching the generated class. Hope this helps.

Resources