I have a situation where I have 4-5 very similar classes which I'd like to re-factor to use an abstract base class.
The idea behind this would be allow methods which could be used by each class whilst adhering to DRY principles.
The problem I have is that these classes are Entity classes generted from EF4 and each time I try to alter my model it seems to break down.
What's the best/recommended, method to add a base class into my EF model and make the existing classes in the model inherit from this as a base? At the moment I've got no problem adding the base class, giving it an ID property as it seems to require, and then creating the inheritence, but EF then moans about
'Error 3024: Problem in mapping fragments starting at line 18563:Must specify mapping for all key properties (MyBaseType.ID) of the EntitySet MyBaseType.'
In this situation I don't want the base type to be persisted to the DB, purely used as a container for base methods common to all the classes which inherit from it. It feels like I'm missing something simple here but I can't for the life of me see it.
Any ideas on how to add in a base class in this way? Or should I just be adding the base class in code and bypassing the model somehow?
EDIT: As further information, take an example where there are say 3 types, MortageApplicationForm, BankAccountApplicationForm and CreditCardApplication form. They are currently stored in 3 different tables, with a set of different fields.
What I'm trying to do, is create a base class of say 'Form' which will have the common fields in it.
At a simple level, say that each table has a primary key ID field called, 'CreditCardFormID', 'BankAccountFormID' etc What I'd like to do it create a base 'Form' class with a property 'ID' which for the case of one table will map to 'CreditCardFormID' and another 'BankAccountFormID'.
I'm happy to do this mapping in partial classes (as I don't want to persist 'ID' to the DB) I simply want to use it in code, so I can write generic methods for things like LoadForm(int ID) without needing to write huge switches for each entity type, or specific methods for each entity type.
I managed to find a work around for this by rejigging things slightly. Firstly, I did not have the time available to rework the model (which I think would have been the best solution) too much of the system has already been developed with the existing structure to rip it all apart at this point.
The solution so far, has been to create a static helper class to contain business logic which is generic accross in my example, the 3 different account types.
This was coupled with an 'IAccount' interface, allowing the helper class to take an IAccount instance as a parameter (allowing the passing of any particular account type.) This interface contained all the common properties accross the 3-4 concrete classes. It was important to note that in order to create generic methods which I could call on all the classes I was not able to use any other properties specific to the class.
Within the helper methods, I needed to switch my concrete XYZEntities instance to a more generic 'ObjectContext' object and then use the methods such as 'AddObject' rather than 'AddBankAccountForm', 'AddCreditCardForm' etc explicitely.
This involved a tiny bit of GetType()'ing to ensure the object was passed to the correct ObjectSet, but seems to work as desired.
There are 3 patterns for this:
Table per Class Hierarchy. All concrete types in the inheritance heirarchy are stored in one table.
Table per Type. Each type in the inheritance is stored in it's own table.
Table per Concrete class. A table for each concrete class but no table for the abstract class.
In your case with the existing tables the Table per Concrete class looks like the best fit.
There is a good description of these options in this book
Related
Nearly in all of the "Abstraction" principle definitions, it says sth. like "Hiding the irrelevant (or extra, not needed to know) codes from the user". And I could not get how this is about "abstraction".
Let's say "This is because we can define the methods in the base abstract classes, and we can use these methods after we created the objects in child classes without knowing the internal functionality" But we could already have base non-abstract classes for this purpose. We could have already created objects and used the functionality of the base class without knowing the internal structure of those methods. How is this feature belongs to "abstraction" ????
The main advantage of creating an abstract base class over a non-abstract base class is, that it can not be instantiated; so it is just be there for creating a "common concept", right? But other than that, i don't see a difference between them in the sense of hiding the internal structure.
Let's say I have 2 types of coffee-machine; CheapMachine and ExpensiveMachine. I created a non-abstract base class and added several methods with definitions like StartMachine(), GetOptimumHeat(), etc. And then I created a CheapMachine instance CP, and called these methods easily, without knowing the internal functionality of these methods.
So, did I use abstraction principle by just creating a base class then?
I am confused like I feel I got the main idea but what would be the best description of this principle? For ex., How would you describe this principle in an interview?
I'm doing these MVC controllers, and I want to reuse the actions (Create, Edit, Delete, etc.)
So far, my Models can implement certain interfaces that only have properties.
For example: If my Model Cat, inherits from ISingleKeyIndexable, that means that Cat will have the property Id, which can then be used to do database queries.
So far I have done something like this:
public class CatController : SingleKeyIndexableController<Cat>
SingleKeyIndexableController has actions like Create, Edit, and Delete. They all depend on the fact that the type given as generic implements ISingleKeyIndexable.
The problem comes when you want to have different flavors of a controller base class. So suppose that some controllers handle Models that are ISingleKeyIndexable, others are IStringIndexable, and others are NOT IDeleteable (so you don't have the Delete action). You would have to define a class for each different combination of those Interfaces, which is not good.
Is there any way to "inherit" (not necessary real inheritance) some methods from somewhere else depending on the interfaces implemented by the model type I gave as generic to some other class, or some other approach to work with this?
In general this is a discouraged pattern (deriving only some aspects of a class) and it's not supported in MVC.
You can however block actions that you don't want available to the client by overriding them and marking them with [NonAction]
I have reverse engineered a MySQL database in a C# desktop app. What I would like to do is extend one of the model classes, so that I can add methods to it to use locally in my application. I don't want to change any properties or anything just. Just get information and calculate things.
The problem is that when I inherit from one of the model classes I get an error about a new discriminator field being in the class but not the database.
Is there a way to do what I want to do?
Given that the model classes are partial, you can just declare your own partial classes to join them:
// Note - needs to be in the same namespace as the auto-generated declaration
public partial class Foo
{
// Add your own methods here, which can refer to the properties declared
// for the same type in the auto-generated code
}
The point of partial classes is that multiple files can contribute source to the same type.
You could try extension methods to accomplish this instead of inheriting and creating a new subtype.
You would "attach" the extension methods to the model class which you generated.
In C# i am making a desktop application which has a list of objects from a class called Task.
Each Task contains some Functions which will be executed by the Task when the Task is executed.
My question is how to manage the Functions since there are many types of Functions, there could be a Function with a class to move (In which case it would need vector data) there might also be a class to wait (in which case it would need some integer data).
What is the best way to go about doing this?
My idea is to have each type of function have its own class (wait class & move class) and all those classes inherit from a Function class which has the function Execute().
But even this doesn't work since I'll need to have the user change the data within each of those objects and since none will have the same type of data it gets very difficult.
This is a question about architecture because i am new to programming and i know i will make a bad call about how to go about it and will make my my program impossible to maintain, the only issue with my current design is changing the child classes of function data, for instance knowing to ask for vector data instead of integer data.
FYI There will be many of Function sub classes i only gave two examples, and each will have very unique data. (Links to resources are accepted)
From what I can make from your post your talking about having Classes that extend a parent class. You would define a parent class (or interface) that would have the base methods for what you're doing. If you choose an interface you just make method stubs. The child class if extending a parent class can choose to override the method. If it is a class implementing an interface the class will be forced to make the methods defined in the interface.
Extend from a base class/interface which has all the methods and use a property grid to populate each sub-class with it's unique class specific data.
I've tried to do this in the designer, but I wasn't able to figure it out. Is it possible to persist nested classes using Entity Framework?
Note: I am just curious whether this is possible or not. I can't think, at this point, if there would ever be a reason to do this, but it might be nice to know how if it is possible.
Example:
public class NormalClass
{
public class NestedClass { }
}
Update:
Danny Varod had a good idea for how to accomplish this. When I have some spare time, I'm going to try it out, and I'll post the results on here, unless someone else gets to it first.
EF classes are declared partial, so you can add whatever you want to them.
Note that the inner-class's properties won't be persisted to the DB, if you want that, use a navigation property instead.
A nested class in .NET is basically the same as a class within another level of namespace (accept for the fact the inner class can access private parts of outer class, as Ladislav Mrnka pointed out - you could use internal instead of private to get around this), there is no change in behaviour (unlike in Java), so there is not much point in using nested classes.
You can define sub objects using complex properties or using a navigation properties, however, complex properties have limited capabilities (no navigation properties or keys in them) and neither are created as nested classes.
To force EF to use nested classes, you could try creating the classes yourself, then mapping them either with a Code-First approach or by cancelling the auto-creation of the class and writing them yourself (or changing the .tt file to created classes nested) and then editing the .emdx as an xml to map entity to a different class.