Click here to Skip to main content
15,881,882 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
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 back door contains data from 6 tables for each combobox.
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
Posted
Updated 29-Aug-12 20:06pm
v2

1 solution

Yes you could take, the path you drafted. What is the goal of the project? I suppose, you want to deliver means to the customer to build it's own trailer, by choosing from predefined parameters. Right? But what do you want from us? Suggestions how to translate this business model to data model? Let's suppose that.

I assume, that the model space is smaller than the Cartesian product of all possible components - there could be exclusions.
I would not store the components in different tables (classes), I would use a single entity, that would contain a name, id, component kind, and if it is needed to store the different parameter information about it, a dynamic part mapped to an XML (or a JSON string, or a simple formatted text depending on platform). In an other table you could store the exclusions.

Using this approach, you are not limited by the number of components, this number can grow or shrink according to the business needs, and the code must not be changed. But you would need to create dropdowns, and possible other controls at runtime. But this should not be a problem.

This is only an approach that I would use, that can (should) be refined based on the actual business needs.
 
Share this answer
 
Comments
deurebokkn 30-Aug-12 7:32am    
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.

records are added, deleted, doesn't have to be shown no more and this is with a few tables with the option choises.
Zoltán Zörgő 30-Aug-12 8:44am    
If the database layer is in place and can not be altered, than forget, what I wrote. But if it can be redesigned, I suggest to rethink the data model. The approach you have drafted has a huge drawback: it is fixed, does not have the flexibility to follow the changes in the business logic (I mean the logic of the company itself), so if a new component is added to the trailer, you will have to change the code. So, what I suggested is to go to a more abstract level, and treat all components (doors, axles, etc...) as just "component" with a specific name, kind (door, axle,...), some specific properties. And in addition store a meta rule set of how these can or can not be combined. You can also specify a path of selecting the components for the trailer. When the user had chosen a component, you can select all further possibilities from that one "component" set based on the rules. Than you can dynamically generate the next set of controls. And so on...
The problem with the relational model is, that third normal form is not how the real word is structured. So if you stick to R or ER on a lower level, you get a frozen model. But if you go a little higher, that level of abstraction lets you be more dynamic. Yes, you will loose BCNF, but even 3NF. But if this is not a learning project, you gain more.
deurebokkn 4-Sep-12 8:04am    
Sorry not really understanding fully atm. thought i did. can u fully explain.
Gonna show u what I posted last with the full explination of the project.

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.

Thanks in advance
Zoltán Zörgő 4-Sep-12 9:01am    
I have fully understood. But I don't know how to explain my points in other form. Bet let's try: you see it right: many classes and hard to maintain. Thus you have thus think from the top concepts down to the database, but it looks to me that the database was designed at the very beginning. Your pattern is good, and can be as dynamic as it needs.
One question: you want to define a separate class for every trailer part, or you want to define a more general tool, that can be set up to represent any trailer part. What I am suggesting is to find a logic for the later.
deurebokkn 4-Sep-12 10:33am    
yea but the customers are already showing.
so it works... I'd like to know how u call the tables for foreign keys.
All the tables just with an id and the explination.
Where would u call them and how?

Thanks a lot!!!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900