In my model I have an Interface IVehicle which implemented by Car, Motorcycle, Train ... classes now I want to use IVehicle as the data source within my viewmodel in binding to the wpf view to benefit using polymorphism so I can switch between Car, Motorcycle, Train ... but I don't know how to implement this scenario in viewmodel knowing that the model getting populated using wcf services.
Thanks in advance.
Related
As we all know about abstraction and encapsulation fundamental that help to build robust and loosely coupled architecture.
When we start designing classes we need to keep in mind the specialized attributes and based on that structure need to build.Usually we go with interfaces or abstract classes for creating a foundation of architecture.
I am confused here with interfaces, weather they are lied under abstraction?
Why they said program to interface, not implementation.
Thanks in advance for clarifying.
If we talk about abstraction it is like hiding the implementation details from user. Like user need to only use the class or function that is abstracted.
If we use abstract class along with abstract method. We have to use all the abstract method (if any) of that abstract class while inheriting that class, But if we talk about interfaces it is not like that.
interface is to reduce redundant data to the inherited class. If we use interface then we can implement any feature or function of the class and write out the definition accordingly.
In short interface is not abstraction.
I have recently looked at an application, which uses the Model View Presenter pattern in the User Interface layer. There are Model classes like this:
Public Class OrderModel
Public Property OrderId() As Integer
Public Property OrderDate() As Date
Public Property RequiredDate() As Date
Public Property Freight() As Single
Public Property OrderDetails() As IList(Of OrderDetailModel)
Public Property Member() As MemberModel
End Class
In the Domain layer, there are domain classes like this:
Public Class Order
Inherits BusinessObject
Public Property OrderId() As Integer
Public Property OrderDate() As Date
Public Property RequiredDate() As Date
Public Property Freight() As Double
Public Property Member() As Member
Public Property OrderDetails() As List(Of OrderDetail)
End Class
Notice that Order and OrderModel are identical. There is a class called Model.vb in the UI layer, which has lots of code like this:
Return Mapper.Map(Of List(Of Member), List(Of MemberModel))(members)
Is it good practice to have two different Data Transfer Objects for each entity in the database? i.e. one DTO in the User Interface (OrderModel) and one in the model (Order) or is it better to have one DTO per entity for both layers eliminating the need to have the Mapper code?
In order to make right decision you should compare responsibilities of models in the User Interface layer and in the Domain layer.
Is it good practice to have two different Data Transfer Objects for each entity in the database? i.e. one DTO in the User Interface (OrderModel) and one in the model (Order) ...
It is quite common approach when people practice Domain-Driven Design. They have Domain Model that knows nothing about presentation (e.g. Order) and View Models (e.g. OrderModel) that are placed in presentation layer.
... or is it better to have one DTO per entity for both layers eliminating the need to have the Mapper code?
If your application is simple enough and your Order is simply DTO that is data container only and has no behaviour, you may have only one layer with DTOs.
Edit:
There is a quote from 12 ASP.NET MVC Best Practices article about working with DomainModel and ViewModels.
Model’s Best Practices
7 – DomainModel != ViewModel
The DomainModel represents the domain, while the ViewModel is designed around the needs of the View, and these two worlds might be (and usually are) different. Furthermore the DomainModel is data plus behaviours, is hierarchical and is made of complex types, while the ViewModel is just a DTO, flat, and made of strings. To remove the tedious and error-prone object-mapping code, you can use AutoMapper. For a nice overview of the various options I recommend you read: ASP.NET MVC View Model Patterns.
I have a few questions about "best practices" in my application structure. I make use of skinny models, and have service layers which do most (all) of the database interaction. The models call the service layer when they need a database transaction.
I also have a factory class which can return forms, models, and service layer classes. This factory class may also return a "search" class which acts as a very simple DBAL and is used by my service layer.
This search class has helper methods such as getAll() and getById().
I'm slightly confused about which parts of my application should have access to the search class; currently my model uses the static factory to build the search class when it needs to retrieve an entity by it's ID. Should my models instead be calling my service layer to make this call, thus negating the need to use my factory class to return the searcher?
I guess I don't like the idea that my database can potentially be accessed from multiple parts of my application, when really I'd rather everything need to go through my service layer first.
Tips and feedback are much appreciated!
I would end up creating a SearchService (which implements an interface i.e. ISearchService) class which the model, or any other code, that wants to access the Searcher would interact with.
This way you keep a clear separation from the Searcher class, or factory, which could change in the future. The other benefit is that, by having all the search related code in the SearchService, it becomes a lot easier for devs to understand the code, since they know that search related code is in the SearchService, rather then dotted around the codebase, calling factory methods, etc.
Also, by using an ISearchService, you allow yourself the option to use Dependency Injection, which is a nice way of having your object initialised for you, and not having to worry about implementation changes.
That's just my preference though, rather then this being a right/wrong way to do things.
I'm working on an application with many inheritance hierarchies that are not directly related.
Do I have to assign a factory method for each hierarchy in the client code to select a certain class from each hierarchy to instantiate upon the user selection through the GUI?
Instead if a concret Factory you may take a look at the Abstract Factory
Abstract Factory offers the interface for creating a family of related objects, without explicitly specifying their classes.
Reference
If objects are not related, I think you can't avoid having a factory for each object. Take a look at the Dependency Injection architecture , it could be an interesting option Dependency Injection vs Factory Pattern
Have a look at this webpage, which demonstrates using the Abstract Factory pattern with multiple inheritance hierarchies: http://www.dofactory.com/Patterns/PatternAbstract.aspx.
I am designing a controller for Mac application in which I have mutiple models which gets data from mutiple sources. For example my controller class is
DataController and Models are (HTTPData, SQLiteData)
How should I use the model classes in the controller, should I just allocate them based on some paramater for type of service, or should I use weak reference?
Thank you for your help.
Maybe try using generalization, that means, having a base controller, and then subclasses that handle the different types of data you support