Take the 2-minute tour ×
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.

What I need to build is a web application that maintains and shows products. A product has a lot of attributes, some that will be changed or added during the next year. I have 2 options for designing the database and the mvc application.

First alternative is using a products table in the database that maps more or less 1:1 to my MVC model object. This will mean that a product have 4-5 item numbers (my ow, my distributors and my customers), 5-7 prices and so on. Coding against this structure is very easy. Mapping to and from EF <-> Model can be done by automapper, the model can have labels/rules for each field, and creating an editable view is almost as easy as doing a right click create + CSS formatting.

The other route is to use an attribute based approach. Here I define a product as basically an ID + a name. All other attributes are placed in its own table where each product has lots of rows and 1 row = 1 attribute. Each attribute then has a type that defines its datatype, display name, allowed values and so on. I then have to code so that all 3 tables are translated into a model, that this model is written out to an edit page (using a loop for each attribute) according to formatting rules defined in attribute type. And that the input data is not only checked against the model, but also against the rules defined in attribute types.

My question is, in this context (MVC 4, EF database first). What approach is the best?

share|improve this question
    
Design the database for the business process, then design and implement your application around the database. Not the other way around. –  Jesse C. Slicer Dec 3 '12 at 14:56
    
Jesse, please explain. DB is just a data store, why would it be the main thing to affect application design? UI and user experience should drive everything else, because they are essentially what user gets and what really matter. –  Kefir Dec 4 '12 at 6:32
    
The business process is the same either way and the UI and user experience is the same, this is about how to BEST write the plumbing code (ie database access and model verification code.) –  devzero Dec 4 '12 at 7:25
add comment

closed as off topic by Jeff Vanzella, svick, Brian Reichle, Paul, Trevor Pilley Dec 4 '12 at 14:32

Questions on Code Review Stack Exchange are expected to relate to code review request within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 1 down vote accepted

Simplicity and less coding is certainly better, so the first approach looks better at first glance. As soon as your attribute set is finite and will settle down at some point, at least.

First approach pros:

  • less coding, faster first iteration
  • straightforward design, easy to understand and maintain
  • most likely better performance

Cons:

  • adding new attribute is probably more expensive (you have to modify db and code)

So the main thing to consider here is the cost of adding new attributes.

share|improve this answer
    
I do not expect the attribute set to settle down ever, but changes are going to be infrequent. They are mostly driven by the adding or removal of product distributors. Thank you for your input. –  devzero Dec 4 '12 at 7:29
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.