Hi I am using EF to generate the classes at the BLL.
Within my classes i have 2 classes named A & B. Both of these classes have common properties so i want to extract the interface named ICommon from them.
My question is ,
Once I take out my interface ICOmmon & how do my EF generated enties implement it?
e.g
interface ICommon
{
int OpenCount{get;set}
}
partial class A: ICommon
{
how do I implement OpenCount property now?
}
Related
I'm using SQLAlchemy and am generating classes dynamically for my database via the Automapping functionality.
I need to add a Mixin class with various helper methods to each of these automapped classes.
I tried to create subclasses of the automapped class with the mixin class:
db = create_engine(connection_string)
automapper = automap_base()
automapper.prepare(db, reflect=True)
for class_variable in automapper.__subclasses__():
new_class = type(class_variable.__name__, (class_variable, Mixins), {})
when I try to use these classes I get errors like:
class _ is a subclass of AutomapBase. Mappings are not produced until the .prepare() method is called on the class hierarchy.
If I call automapper.prepare() again, I get warnings like this and mostly just enters an infinite loop:
SAWarning: This declarative base already contains a class with the same class name and module name as sqlalchemy.ext.automap.payments, and will be replaced in the string-lookup table.
I cannot specify the classes explicitly as in this answer, because I don't know the database tables ahead of time.
From the docs, you can augment the Base with your Mixin class. In this case, you could pass your Mixin as the cls parameter.
automapper = automap_base(cls=Mixin)
recently I was assigned to develop an use case diagram and a class diagram for a conference management system. First I developed use case diagram and then class diagram. In the class diagram I have the following unclear parts:
Do we need to show get and set methods for all the private fields in every class. Or we can omit get and set methods, since it is obvious.
Do we need to show the constructors in a class? If it is not necessary, what is the reason for not showing them? I have seen lot of class diagrams without the constructors but the reason for that is beyond my understanding.
Gets and sets methods are not UML definition. It is just way how to manipulate with attribute values in some programming languages. Pure UML know attribute , its type, name and other properties.
Typical usage of getters and setters in programing is to implement readonly or derived (calculated) attributes.
You do not have to define getters and setters in uml class diagram.
Constructor:
You can define constructor operation in class of course. Constructor operation has keyword "create" at the beginning of its name. You can assign behavior definition to constructor as its method to define how to construct instance of class.
See Common Behavion in UML Superstructure.
I will use LINQ-to-SQL when the database is ready and use the entities there as models in my aplication. I'm trying to program against a interface to make changes to the program easier and I just realized that if I would later change from LINQ to something else I would have to create new model objects that would represent something very similar to the LINQ entities.
So I thought of creating interfaces for each entity and expose the properties and methods I would use in the program and aren't LINQ specific. But when I would apply this interface to the entity class would the implementation automatically bind to it's properties.
I'll give you an example to explain better.
I have table Cars that amongst others has the columns producer, type and wheels
So I make the interface ICar
public interface ICar
{
string Producer { get; set; }
string Type { get; set; }
int Wheels { get; set; }
}
The Car entity object will have these exact properties so will that work as the implementation of these properties or will they be defined seperatly so you get ICar.Producer and Car.Producer in the class?
This might be helpful: Linq to Sql, Programming Against an Interface and the Repository Pattern
First link is broken, check here instead: ORM and Repository pattern
In LINQ to SQL, Can we inherit our entity classes from some other class or interface.
I have some common work for all my entities, which I want to code at some common place
and call it once.
Regards
Parminder
#Jason's answer is useful for manually tweaking each class. To modify all generated classes to use the same base class there is an attribute in the .dbml file that can be edited manually (no UI for it in VS2008).
Add a EntityBase xml attribute into the <Database> xml element, its value is the full name of the base class.
<Database ... EntityBase="MyNamespace.MyBaseClass" ...>
...
</Database>
Its used by the LINQ to Entity Base project.
Yes, this is possible. Use partial classes. If MyEntity is your LINQ to SQL entity class, add a partial implementation as follows:
partial class MyEntity : MyBaseClass, IMyInterface {
// do it
}
You can even make your entity class an abstract class.
I am making ajax calls to my webservice (using MS ajax framework - Telerik comps uses it actually). I am returning one of the Entity classes generated by the dbml. It used to work fine, but when I added the associations it started throwing an exception on the server, saying "a circular reference was detecting when serializing type "
I worked around it for now, but I'd really like to know what is happening. Thanks
This is because the relation is mapped with navigation properties both ways. ie you can use:
myCustomer.Orders
but also
order.Customer
You could try marking one of them non-public in the dbml, then if you need a public property, create it in the partial class, so you can mark the property with XmlIgnoreAttribute:
partial class Order
{
[XmlIgnore]
public Customer Customer
{
get { return InternalCustomer; }
set { InternalCustomer = value; }
}
}