|
See the following links[^]
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
We have to create some integration web services and were thinking about best practices. Should we favor flattening out the object model or be verbose (leave less room for interpretation/error)?
Example 1. Complex Types – The employeeListItem would be used to provide summary information about the employees. The salaryEmployee and hourlyEmployee would be used to provide details.
<employeeListItem>
<employeeId/>
<firstname/>
<lastname/>
<type/> (‘Salary’ or ‘Hourly’)
</employeeListItem >
<salaryEmployee>
<employeeId/>
<firstname/>
<lastname/>
<dateOfHire/>
<officeId/>
<salary/>
</salaryEmployee >
<hourlyEmployee>
<employeeId/>
<firstname/>
<lastname/>
<dateOfHire/>
<officeId/>
<hourlyrate/>
<hoursPerWeek/>
</ hourlyEmployee >
Example 2. Flatten objects – Just one type here all the details are provided in one object. When an employee is of type ‘Salary’ the ‘hourlyRate’ and ‘hoursPerWeek’ will be unused.
<employee>
<employeeId/>
<firstname/>
<lastname/>
<officeId/>
<type/>(‘Salary’ or ‘Hourly’)
<salary/>
<hourlyRate/>
<hoursPerWeek/>
</ employee >
Of course our objects are not as simple as this example but this general idea. So what would you guys favor 1 type or 3 types in this scenario?
|
|
|
|
|
There's a lot more to this question than this. Is this object going to be used on its own, or is it going to be in a collection? Instinctively I'd go with a normalised version of the object, but it really does depend on a lot of other factors. In the end, you're going to have to do a bit of profiling and work out what the size of the object you are going to be passing over the wire is, and if it's acceptable to you.
Unfortunately, there's no magic bullet that we can apply here. This one's up to you.
|
|
|
|
|
Hi everyone,
I am a software developer that is looking to improve the way I design my classes...
In my classes usually I have a constructor where an ID or some identifier is passed in, the constructor then goes off to the database and populates that objects member variables.
A 'save' of an object would find the relevant record in the database and overwrite it's data.
What's all this I've been hearing about a separate data access layer - how would you go about implementing one.
I have been thinking for a while that this is a bad design (should you get the data before
you create the instance of the class and pass this to the constructor?)
and if this is the case, wouldn't you just be moving the SQL into the UI or the calling method...
Does my way of doing this look as messy as I feel like it does; and is there any way around having to code each and every member variable into the class, and corresponding GET/SET methods? It feels like each class I design takes at least an hour each to hand code all the even generic getters and setters never mind the logic of the actual class itself and then is full of messy SQL Select and Update statements.
I guess I'm after a pointer to an 'architecture 101' type tutorial 
Thanks in advance for any pointers/ideas.
|
|
|
|
|
|
Thanks for your reply, however I usually do Google, and have only come to a forum on this one occasion to engage in a discussion rather than look at dry documents.
|
|
|
|
|
daniel.byrne wrote: rather than look at dry documents.
Dry documents published by well established leaders in the industry are far more valuable than, never mind.
Well that just proves you have no experience on c2.com since there are some extensive discussions on that wiki. Ok, I know return you to your regularly scheduled program of burying your head in the sand.
led mike
|
|
|
|
|
First of all, thank you for your link. It has been bookmarked and I am going to give it a read.
I'm sure you have your uses here but being personable is obviously not a strong point of yours ledmike. If you are trying to be helpful or teach someone then being a condescending troll is not the best way of going about it. However, if your intention IS to be a troll, then well done friend.
If you had considered this topic to be 'beneath you' then nobody was forcing you to post your stereotypical RTFM comment.
Is the rest of this forum so unfriendly to people that are just trying to learn?
I won't be sticking around to find out.
|
|
|
|
|
For better or worse that is simply Mike's personality (at least here on CP) so take it with a grain of salt. He actually seems to be in pretty rare form today.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
daniel.byrne wrote: I'm sure you have your uses here but being personable is obviously not a strong point of yours ledmike.
there is nothing in my first reply that is not personable. You chose to respond to my help by calling the links I provided "dry documents" when clearly you could benefit from reading them. There are many people that come to code project that truly desire to improve their skills and welcome any assistance. I have no patience for the others.
You can lead a horse to water but you can't make him fish. Good luck.
led mike
|
|
|
|
|
"there is nothing in my first reply that is not personable."
Yeah, "There is also this thing called Google that will find information for you."
Real personable.
|
|
|
|
|
daniel.byrne wrote: I have been thinking for a while that this is a bad design (should you get the data before
you create the instance of the class and pass this to the constructor?)
and if this is the case, wouldn't you just be moving the SQL into the UI or the calling method...
The whole point of a DAL is to abstract the "messy" part of retrieving data away from the UI which should neither care nor know how the data was retrieved or stored in the first place. That's not the job of the UI. The DAL is the place to manage the whole CRUD operations.
A common technique for data access is to provide a static Fill method that returns you an instantiated version of your model. This method could (for instance) use a DataRow to populate it's own information, so you'd have a controller class which retrieved a set of data (in the form of a DataReader) and then populate a collection of your model simply by "Filling" each item in the collection. BTW - there are some excellent code generators that automate the tedious process of getting the data out of the database and into your model.
|
|
|
|
|
We have a client driven app, each client has a number of delegates. We are designing a system to manage these and are currently trying to work out the objects.
A client has many delegates, and so should the client object contain a list of these delegates? If so that means that when an client is loaded from the database each of the delegate objects would also be loaded (is this too tightly coupled? There could be 100s of delegates associated with any given client)
The reason that the delegate need to be associated with the client is that, when the client is loaded the associated delegates need to be displayed with basic read only information (this information is unknown at the minute, but will include name, email, phone etc).
On the other hand if a delegate is loaded then, basic read only client information needs to be displayed on the delegate record. If we then referenced the client from the delegate, this would cause a loop of reference meaning that if you load a delegate or client all associated delegates would be loaded.
Any suggestions of a class design or design pattern? I feel that others must have done this?
|
|
|
|
|
Its hard to understand your question, because both the word "client" and "delegate" have lots of meanings. But I think I understand.
You have a master-detail (one-to-many) relationship between clients and delegates, and you want to have a client object with a property that contains a collection of delegate objects. Each delegate object will have a property reference back to a client object.
The simple solution is to use lazy-load properties. (Have the necessary properties, but only instantiate the actual objects the first time the properties are used). This prevents the "loop" scenario you mention.
If it is a small .NET app, then you could consider using Castle ActiveRecord, which will do this for you. (Or any OR-Mapper will also do it).
|
|
|
|
|
Many Thanks for your reply
I think you understand my problem!
using lazy-load properties would be ok, but..
I will have a screen showing client information (ie, linked to an instnace of a client class), on this screen i need to show basic information about each delegate at that client (say in a datagridview, and when they click on a delegate it opens a delegate screen), so i would end up loading each delegate anyway.
The only way i can think of doing this is to have a cut down delegate class that is used for displaying on the client screen and then if that client is selected to be loaded, create a full delegate instance.
I just worry that this could result in loads of different types of cut down delegate classes, if a delegate summary needs to be shown on any other forms
|
|
|
|
|
I have a module that accepts a datatable as a parameter.
It performs some operations on that datatable to return some useful information.
The problem is that my datatable provided to this module as parameter has to be in a specific format. i.e for start it needs to have 3 columns for it to be usable by my module.
So what and where and how will be the best way to specify the format required. so that any module , service, application or layer is only able to provide the datatable in correct format to this module.
hope i made my self clear.
thanks a lot
regards
joysnlove
|
|
|
|
|
Could you use a class structure instead of a datatable? That way you could specify what type you needed passing in.
eg
<br />
class Foo<br />
{<br />
int col1;<br />
int col2;<br />
string col3;<br />
<br />
<br />
}<br />
<br />
public bool myfunc(List<foo>,......)
modified on Wednesday, March 5, 2008 7:04 AM
|
|
|
|
|
joysnlove wrote: So what and where and how will be the best way to specify the format required. so that any module , service
The key thing here is service. If you look at exposing your method so that it can be used in an SOA scenario then you shouldn't use a DataTable or a DataSet. These are cumbersome objects that aren't natively recognised by other technologies (such as Java). You've already found typing issues with the dataset, so now you need to consider whether or not this really is the way forward.
|
|
|
|
|
Hi Guys,
I have a question about ImageList strategies. Originally i created an image list for each control, but this didn't expand well, especially when i wanted the same icon in multiple locations. I made a few image lists that covered particular sets of icons as well, this seems to work well, but again suffers from cross cutting issues.
My thoughts for a solution would be to put two image lists in an IOC container and have the application setup the display components based on this. Is this viable?
How do other people manage application wide image lists in their apps? Also, what mechanisms do people put in place for managing Image Keys when the images are dynamic?
Cheers
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
modified on Monday, March 3, 2008 8:18 AM
|
|
|
|
|
Tristan Rhodes wrote: How do other people manage application wide image lists in their apps?
Static image lists. I tend not to work with dynamic image lists, so this strategy works well enough for me.
|
|
|
|
|
Hi Pete,
Is that static as in statically declared, or static as in unmodified? I get the impression you mean both.
The Icons are not fixed and may change. Quite a few of them are pulled out of a CE Database but i don't think there will be any threading issues as the app is (currently) single threaded.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I mean both, but the principle should be the same for you.
|
|
|
|
|
I was hoping someone may be able to give me some feedback on my design principles. I have done alot of applications relating to databases etc in c# but this is my first try at a Client / Server application. I wannted to check some of the recommended ways of performing client / server actions.
The application is basically a front end for a database.
Basically my program will consist of a server application which will have a connection to a database. When a client wants to see records from the database they send a request to the server, which in turn connects to the database, retrives the records ands sends the record data back across the network stream and the client parses the records and displays them. Does this sound like a standard and solid principle?
Thanks in advance
|
|
|
|
|
Yup. It's part of the classic n-tier pattern. Generally you have a UI, a Business Layer and a Data Access Layer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
