Last post Mar 04, 2014 05:59 PM by Anirban100
Mar 03, 2014 02:04 AM|Anirban100|LINK
I am involved in a e-commerce application development. What i have done created the DB/DAL architecture.
Here is what i have done.
Public interface IProduct
Public class Mobile:IProduct
Public class Camera : IProduct
At DAL. I am using repository pattern and here is the class
public Interface IRepository<T> : Where T :IProduct
Public class DataRepository<T> : IRepository<T>
I are so far so good with this architecture.
At controller and view label i am using one generic view and one generic controller.
based on the requested data i am passing different T to the IRepository and it is returning me different value.
Suppose URL is like"..\Mobile" I am passing <Mobile> to IRepository. And now we have decided to use UNITY for DI.
Here we are stuck. Passing dynamic value to product controller giving me some sleepless night.
Also i am concerned about this generic controller/View architecture. as we are using generic controller/view, Views are not storngly-typed. they are dynamic.I am using reflection to determine the propertied. Is it a correct architecture in terms of maintainablity
and scalibility? Sould i go and create differnt stronly-typed view for each type of product?
Having said that i am not doing much in controller(no complex data manipulation) so if i create strongly typed view and one controller for each type. Won't it require me to write duplicate code. Isn't it again against architecture? Can you please provide
Mar 03, 2014 04:36 AM|AidyF|LINK
You should just have a Product class and a view that shows that product. Don't bother having a different class for each product type, make the product type a property of the product if you need to classify it. If one product type needs something another
doesn't (eg a CD will have a track listing but a camera won't, however a camer might have technical specs and a CD won'), then make your product support everything and the view will show/hide things depending on what the product has. So a product will have
both a track list and technical specs, but for a CD the track listed is populated but not the tech specs, and for a camera vice versa. Your view will show the track list if the product in the model has one otherwise it doesn't, same with the track listing.
Having a class for each type is going to lead to a lot of duplicate code and you tied up in knots.
Mar 03, 2014 02:05 PM|Anirban100|LINK
So you are suggesting to create only one model that contains all the properties from each type.Correct?
That make sense. I have one question though. Suppose i am following your architecure. Then the product class will have a lot of properties.
Some them won't be populated. But still in that case the Product object will take a lot of memory.
then passing list<Product> to the view will not cause any performance issue?
Mar 03, 2014 04:39 PM|AidyF|LINK
Rather than specific properties you could look to possibly make them dynamic. So you would have a property collection that is a name\value pair. So maybe a
And a camera would have the key of "Technical details" and the data of "35 mm lense etc etc" whereas a CD would have "Track listing" as a key and a list of tracks as the data. That way you're not wasting space. It all depends on how varied your products
are. Most sites get away with just the description and maybe a handful of special properties.
Mar 04, 2014 05:59 PM|Anirban100|LINK
Thanks man. thanks a lot.
I will create sepecific properties that is common to all product. like all of them will have price. and for special property i will create a dictionary. In this way i will have only one model. and views can also be strongly-typed.
I wonder why this simple idea not came to me earlier.
Thanks again for your time.