Large project. How would u write the classes.

I'm writing a program and I could use some inspiration with the classes.
The pattern is already in place (using mvp because they want to expand to both website and phone in about a year). With a data and a business layer.

Background information
But it's about making trailers for trucks.
So the program has four catogories of trailers.
One trailers contains about 200 specifications.

Problem
Now I'm using about 35 user controls, so I can re-use them.
They all work with comboboxes so u can just choose between it.
Quick example:
U have axles, Different back doors, Bumper, Measurements.
The combobox datasource, value is in the table with the data of the vehicle.
the display member is in each a different table with a relation between it.

Possible solution
Have a class for every table. Then have another class for every usercontrol where you implement it.
Then 1 class for the trailer.
But that is alot of classes?

Any other suggestions

Thanks in advance

Your question is very general and difficult to answer or even comment on without a lot more information about what you're trying to do. From what you've posted, I don't see need for classes for the components. Maybe a trailer class with enum properties built from the tables, like Trailer.BumperType = BumperType.ChromeWithPlayboyEmblem

if your components are only features/parts that go on a trailer (properties), and you don't need to act on them (like Bumper.IncreaseAlloyHardnessToImproveCrashResistance("15mph")), then I don't see the need for classes.

Just a thought. If you have any specific question I'm sure you'll get responses from people much more knowledgeable than I. Good luck!

Ok let me explain a little bit further.

The goal of the project is that the designers fill in the whole thing so everyone can look in to it in the company at the moment.
It's with a database that contains all the options in different tables and 4 tables with the different foreign keys (4 types of vehicles).
I could make classes with the id and the explanation (get and set).
But I know that it would be with a lot of classes so I tought that there was maybe another suggestion. It's a project with presentation layer (model, view, presenter), wcp, data layer, business layer.
So the data layer gets the data and keeps the connectionstrings and the sql strings. business layer contains the business objects with the validation. the wcp transfers data transfer objects to business objects and back.
Now it's to get the data for the comboboxes, how do you mean single entity? It's to transfer the data from the data layer to the presentation layer.

With enum classes. is a nice option but the tables change some times. records are added, deleted, doesn't have to be shown no more. and this is with a few tables.

Yeah, you could use constants to create the dynamic equivalent of enums, but that would get complicated. Maybe a single generic "addon" superclass that contains fields to describe/manage the basics (like addon.TypeofAddon = "Bumper") and methods to load genericinformation form tables. Then you could use inheritance and overrides for the tables which did not fit the generic mold. I don't know how similar the properties/tasks are for your data, but whatever level of data detail you're thiking of making classes at, see if you can't move one layer up and encapsulate them that way. Instead of four separate classses for vehicle, why not one with vechicleType as a field, using inheretance for the various addons in a similarly generic addon class?

I'd approach the problem starting with the database design. I would create a trailer table and an specification table and probably a specifications options table.

These tables would be used to define the metadata of what specifications are available for each of the trailer models. In other words, this info ultimately is used to display what the user can select (once a user selects a trailer).

Any user selections would end up getting store into separate tables (so we aren't storing the metadata in with the user selections).

In terms of class design - it's straightforward for the metadata. You can return a trailer collection. Each trailer contains a specification list and each specification item constains a list of specification options.

When a user makes a setting, just store the trailer setting and the specification list. If the specifications are optional. I would just store a specifications list for only the selected options. So if there are 200 specification possibilities for a trailer, but only 50 specs selected, the specifications list for that user would only contain 50 entries (instead of 200 with several of the specs defaulted).

In terms of using comboboxes for users selections, I would avoid this design. The reason is that no user wants to look at a display with 200 comboboxes. Instead I would group the specs into related categories and allow the user to choose options from each categories. You may still use comboboxes to achieve the user selection, but the user doesn't have to deal with 200 comboboxes all at once.

Wow, Arjay - now I know why you're a 3,000+ rep - I can't believe you got all of that from the OP. I was cnfused as h-e-double hockey sticks but just trying to throw anything helpful because the question had gone so long without a response. I bow to you digitally! It's been great working in threads with you because I know my answers are like crap compared to yours and it's a real learning experience to be "outdone" and learn how I *could* have answered. =)

mrgr8avill, you are new to the site and have been posting a lot of replys helping folks out.

So welcome to the site and thanks for taking the time to respond. :thumb:

thx for the reply.

From ground up. The data is saved in one table trailer that all have in common.
The other data is saved just with the foreign keys => specification table.
The database is designed pretty well I think thats not the problem.

Now with the program.
It isn't all comboboxes and stuff. also checkboxes and text fields...
It depends on which trailer they choose.

The problem is my design pattern I think. (too frozen)
Now I work with
-> form: makes the controls that are needed for that form
-> control: makes the new presenter(s) that are needed for that control
-> mvp: The view contains an IList of the model, the presenter calls the display view.IList = Model.GetIList,
the model.GetIList contains a request and response to the wcfservice.
-> wcf service: returns the response with a call to the dataAccess layer and changes the Businness object to data transfer object.
-> DataAccess: The data access layer contains the cnn-strings and puts them in a list to send back to the wcf service.
-> wcf service: return the dataTransferObject
-> mvp: The model changes the dataTransferObject back to business object. returns it to the presenter.
-> control: Gets the business object and returns it in to a list to show in a listbox or combobox.
-> form: shows the end result

With the lots of data you can select.
It's a lot of work to make all classes and maybe not so easy to maintain.
(it's not the work for the classes but I think it can be done easier).

Hopefully u can give me some insight how it would be done easier.
I designed it that way so it would be easily exported to website/GSM application.

Already thanks for the comments.

The multi-tiered architecture is the way to go.

You can simplify the designs and flatten the tiers by combining many of the layers, ... but I wouldn't recommend it.

The reason being is learning how to think in terms of Model/View/Controller (or any of the other view based design patterns) is very powerful.

The provide a separation between the different layers and ultimately add the ability to make code maintainance and debugging to the code. Yes, at first it's more difficult to debug through the various layers, but once you learn this pattern, you will know pretty much at what layer a problem is at and be able to fix it immediately (and usually without effecting any of the other layers).

Sorry for the late reply was on holiday.

What I mean is:
The comboboxes must all be selected.
So it's only how u would fill the comboboxes.
Even if it were only 50 comboboxes the question is:
How would u do the databinding of the comboboxes because they all have an Id and a showing description.
Would u create a class for all 50 comboboxes or ...
Because I think it would be to much work to maintain this.

It's just the problem with the comboboxes that I would like to understand the rest is ok.

Thanks in advance

I would be the client app using WPF, create a list view (with a template for each row that contains a description and a combobox) and bind the whole thing to a collection.

The added benefit is you would be able to scroll the comboboxes up and down. Let's face it, a UI with 50 comboboxes on a screen isn't a joy for a user to work with, so you want to do everything possible to improve the user's experience.