After reverse engineering code first, I got entity classes and mapping. Most of the business classes (that I already have) have the same name as entity classes and most of the properties in entity and business classes are the same.
If I understand the implementation right, I should make partial classes with entity classes having all the properties and change the business classes by removing those properties and leaving only the business rules.
If that is correct, what to do about derived classes? Obviously entity classes need all properties from base class. Can I change the code in the entity classes so that the entity classes also inherit from the base classes?
Any thoughts would be welcome.
Perhaps you should remove your business classes. ORM is tool for loading and persisting objects - you don't have special set of objects for persistence and special set of objects for business logic. Use single set which consists of persisted properties and computed properties + business rules executed on persisted properties (store them in partial class). That will form something which is commonly called domain object - it has both data and logic related to its data. You can have separate classes performing logic on multiple domain objects (so the logic doesn't belong to the object itself). These classes are commonly called domain services.
are you saying that most of the properties in entity and business classes are the same ? It shouldn't be like that. Business classes should have only the business logic not the properties of entities. Business class will use entity classes to fulfill the business.
Here is a good example http://code.msdn.microsoft.com/ASPNET-MVC-Application-b01a9fe8/
Related
I have a WPF MVVM app with 3 layers:
UI
Services
DAL
and some item, for example Order. I need 3 DTO:
Class for MVVM layer, with PropertyChanged notification;
Class for Json deserializer (get objects by REST API)
Class for Entity Framework (cache data in DB).
Well, I can use ONE class for all three cases, but this will be mix of different attributes (from EF, JSon, MVVM) and excess dependencies of layers.
Another way: make 3 classes, each layer has own class, and use AutoMapper for fast convert between. No bad, but 3 almost identical (90%) copy of each DTO class... not elegant solution.
What is the best approach? What do you use?
Thanks.
What is the best approach? What do you use?
The second approach, i.e. you define your business objects in a separate assembly that you can reference from all your applications. These classes should not implement any client-specific interfaces such as INotifyPropertyChanged but be pure POCO classes that contains business logic only.
In your WPF application, you then create a view model class that implements the INotifyPropertyChanged interface and wraps any properties of the business object that it makes sense to expose to and bind to from the view.
The view model then has a reference to the model and the view binds to the view model. This is typically how the MVVM design pattern is (or should be) implemented in a WPF application. The view model class contains your application logic, for example how to notify the view when a data bound property value is changed, and the model contains the business logic that is the same across all platforms and applications.
Of course this means that you will end up with a larger number of classes in total but this is not necessarily a bad thing as each class has its own responsibility.
The responsibility of a view model is to act as a model for the application specific XAML view whereas the responsibility of the model class is to implement the business logic and the responsibility of the DTO class is to simply transfer the data between the different tiers. This is a far better solution - at least in my opinion and probably in most enterprise architect's opinions as well - than defining a single class that implements all kind of UI specific logic just for the sake of reducing the number of classes.
I am trying to get some design validation on modeling a domain using EF4.1 and T4.
At design time I run a customized a T4 poco generator template that reads edmx and creates 3 partial classes:
1) domain-level class (where any specific business methods will reside). this is only generated one time. Once Gen'd it's owned.
2) poco class just properties and virtual navigation properties to related objects, loaded lazily. this can be regen'ed if/when any underlying columns in the database change.
3) metadata class with an internal class whose properties are decorated with data annotations to provide additional column-level validation before inserting / updating data.
Is this overkill? I liked the separation, namely between the poco and domain object so that I can add methods to the partial domain object at any time without having to worry about method loss when needing to rerun the T4 template after underlying data specs may change. What about the metadata class? Is that unnecessary if my application will be performing field validation?
I want to add browsable attribute to some properties for entities generated by LINQ to SQL.
Is it a good idea? Since these entities are auto-generated, and when I regenerate they (the attributes I have added) might be overwritten.
I would probably use Damien Guards LINQ to SQL T4 templates, and modify the template to include the attributes you need. Then the attributes will be generated when you regenerate the classes.
You cannot add additional attributes to the properties in another partial class file because you would be defining the property more than once. This is one reason, among others, that we created our own code generator that generates L2S entity classes the way we want them.
Our code generator also generates a second set of 'application' entities that are much more lightweight than the L2S entities and used at the application level. They contain no L2S plumbing, but do contain other characteristics that the application level finds useful.
I guess the question title sums it up. Is there a time when it would be considered good design for an ABC to have data members? I have been wondering if there is a situation where this is OK. The only ones I can come up with all are static, and even then it's kind of a stretch.
I don't see why an ABC couldn't properly have per-instance (aka non-static) data members, as needed to support the methods it supplies to subclasses. Take the common case in which an ABC exists to supply a Template Method DP (the hook methods being abstract) -- if part of the function of the organizing method is to update some instance variables (for example, a count of how many times the method was called), then obviously those variables should also be supplied by the ABC. Can you explain better why you think that's bad design?!
An abstract class can have whatever members it needs to support the functionality it supplies to the classes that inherit from it. That's not to say these would be directly accessible to the subclasses: they might be read and changed only through method calls made by the subclasses or their clients.
I see this in plugin architectures, like Paint.NET's.
Inversion of Control might require this. For example you have a bunch of classes that take an instance of Logger, the abstract class they're based off might have a constructor store it in an member variable or private property (assuming of course you remember to call the base constructor grin)
It is OK, when your data member in your abstract class contains base code for inheriting classes
I would think about using an interface, when the data member is just to describe your class
Yes, its possible to provide member variables in an abstract base class with the intention that its subclasses will use those members to make a concrete implementation.
Here's a concrete example, using a car analogy that we've all come to love.
Let's say we make Car an abstract base class, which has placeholders for wheels, chassis, and an engine for its its subclasses to use:
abstract class Car {
Wheels wheels
Chassis chassis
Engine engine
abstract void accelerate();
abstract void decelerate();
}
Now, for a class that extends Car, the members are already there to use, so the responsibility of a subclass is to populate those member variables:
class NiceCar extends Car {
Decoration decoration;
public NiceCar() {
wheels = new ChromeWheels();
chassis = new LightweightCompositeChassis();
engine = new LotsOfHorsepowerEngine();
decoration = new CoolRacingStripes();
}
void accelerate() {
engine.feedFuel();
}
void decelerate() {
wheels.applyBrakes();
}
}
As can be seen, the abstract base class can work as a blueprint for which components (member variables) should be filled in to get a full functionality of a class. In this case, the Car provides basic parts of a car to be used in a concrete implementation. NiceCar uses those member fields and adds some for its own features, such as a decorative paint job.
I suspect that you are drawing too tight a circle around your concept of an abstract base class.
An abstract base class (as opposed to a pure interface) is a class that intends for some of its functionality to be used by child classes. It will thus have some functionality along with methods that are intended to be over-ridden (the interface part). There is no reason why this functionality should not have member variables associated with it.
Many frameworks are based off of inheritance. These will almost inevitably have abstract classes with member variables. For instance, DirectShow is the multimedia streaming framework in Windows. The sources, encoders, decoders, etc. are all implemented in what are called "filters". There are base classes for various types of filters. Each of them will have member variables for the upstream and downstream filters, the negotiated media types, etc.
As others have mentioned one adds instance fields to any sort of class when one needs to store state. This holds true of abstract or concrete classes - there is no difference.
Why should it make difference ? After all an abstract class is just like anyclass except it can't be instsntiated, requiring subclassing etc to complete the class.
If it's a state used by all inherited classes, I think it's mandatory to move it to the base class. Even though the base is abstract. I think most people that are into refactoring would agree with me on this.
There might be several reasons why some state should be in the base. Reducing code duplication is a good reason enough.
This question already has answers here:
Interface vs Base class
(38 answers)
Closed 12 months ago.
I have been getting deeper into the world of OOP, design patterns, and actionscript 3 and I am still curious how to know when to use an Abstract class (pseudo for AS3 which doesn't support Abstract classes) and an interface. To me both just serve as templates that make sure certain methods are implemented in a given class. Is the difference solely in the fact that Abstract classes require inheritance and an Interface merely extends?
Use an abstract class if you have some functionality that you want it's subclasses to have. For instance, if you have a set of functions that you want all of the base abstract class's subclasses to have.
Use an interface if you just want a general contract on behavior/functionality. If you have a function or object that you want to take in a set of different objects, use an interface. Then you can change out the object that is passed in, without changing the method or object that is taking it.
Interfaces are typically loose, compared to Abstract classes. You wouldn't want to use interfaces in a situation where you are constantly writing the same code for all of the interface's methods. Use an abstract class and define each method once.
Also, if you are trying to create a specific object inheritance hierarchy, you really wouldn't want to try to do that with just interfaces.
Also, again, in some languages you can only have a single base class, and if an object already has a base class, you are going to have to do some refactoring in order to use an abstract base class. This may or may not mean that you might want to use an inteface instead.
As #tvanfosson notes, it's not a bad idea to use a lot of interfaces, when you really understand abstract classes and interfaces, it's not really an either/or situation. A particular situation could use both abstract classes and interfaces or neither. I like to use interfaces sometimes simply to restrict what a method or object can access on a passed in parameter object.
Abstract classes offer the possibility to implement specific methods and require others to be implemented in the inheriting class. With interfaces, everything has to be implemented in the implementing class.
As #m4bwav notes, the primary difference is that an abstract class can, and often does, provide a default implementation for at least some methods. This allows you to use the abstract class to keep your code DRY (don't repeat yourself), by keeping code common to all classes that inherit from the abstract class in the abstract class itself.
I think it's a false dilemma, though. You don't need to and arguably shouldn't choose between interfaces and abstract classes. In most cases, you would want to define the interface, then have your abstract class provide a default, skeleton implementation if one is required/desired. For me the question would be do I need an interface or an interface and an abstract class rather than an interface or an abstract class. Using the interface decouples your code from any particular implementation, even your abstract class implementation. If you should choose to have an alternate implementation, using the interface would allow this whereas if you only had the abstract class, you'd have to refactor to add the interface later.
The only situation where I can see that providing an interface in such a situation would not be desired is where you want to restrict it so that only your implementation can be used. Using the abstract class and having certain methods be not be virtual would enforce the use of your code in all circumstances where the implementer is deriving from your class.