Click here to Skip to main content
Rate this: bad
Please Sign up or sign in to vote.
See more: C# Model
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.
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 29-Aug-12 20:58pm
Edited 29-Aug-12 21:06pm

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

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.
deurebokkn at 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ő at 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 at 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ő at 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 at 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!!!
Zoltán Zörgő at 4-Sep-12 14:57pm
I said that you are sticked to these concepts. The database is just a repository, it is not the first level business model anymore. Your pattern is missing the business layer, I suppose it is embedded in the WCF service. Foreign keys and such things are good, but not needed if the business object layer (model) is responsible for that. The database should only store data, bot the layers above should give the meaning to the data. Thus I will speac not about tables.
First I would define a metadata syntax that could describe any business object (trailer part) I might need. This one can be a class library tagged with DataAnnotation attributes for example - but without any concrete mapping to a table. This is my business object model. I need a factory that can create a form content descriptor from a business object; and one that can validate submitted data and create a business object from the submitted form. Of course I need the business logic, to process the data. I need a presentation factory, that can render the form based on a descriptor (xaml if you wish) and the content. And I need a serialization engine, that will map my business objects to a general table (or few tables) - I am a big fan of JSON.
This way I can expand my business object model without the need to add or change tables). How do you separate these layers, and how do you perform the data exchange between them depends on you.
This is how I would proceed.

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

  Print Answers RSS
0 OriginalGriff 381
1 Sergey Alexandrovich Kryukov 245
2 Marcin Kozub 225
3 Praneet Nadkar 217
4 /\jmot 189
0 OriginalGriff 8,284
1 Sergey Alexandrovich Kryukov 7,407
2 DamithSL 5,614
3 Maciej Los 4,989
4 Manas Bhardwaj 4,986

Advertise | Privacy | Mobile
Web02 | 2.8.1411023.1 | Last Updated 30 Aug 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100