|
Yes, that's exactly what I am saying. Don't feel stupid, it's coming to realisations like this in a real world scenario that teach more than just the written word can ever hope to.
|
|
|
|
|
Makes perfect sense! Can't believe I didn't think of that. Oh well 
Would still be interesting if anyone else has another approach. There is often more ways then one to skin a cat 
|
|
|
|
|
I've been trying to figure out what would generaly be a better course of action regarding Business objects. I have a few options, and i was just wondering what methods other people use, and in what situations.
1) A Data Object with a support object for manipulating data.
2) A Data Object with integrated data manipulation.
3) A Data object with a supporting data manipulation object that can be injected into the Data Object and used to manipulate Data via proxied functions. (A kind of hybrid, almost like injecting a DataAdapter.)
Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
But this isn't always sound advice when someone already has the requirement to build their app to be compatible with both Oracle and MS-SQL.
Rarely do they have the option of changing storage mechanisms. Alot of the times clients already have thousands invested in their database, and just want an app to couple with existing apps and data.
How would you treat a scenario where you had to be able to work with a set of objects that could either be loaded from an Oracle or MS-SQL database, or be loaded from an application server?
You don't have the option of using your page based db either. You can use PE but it has to be able to talk to an app server over tcp/ip, Oracle, and MS-SQL?
I appreciate what you are trying to convey by exposing people to these simpler models, but when someone is asking for advice for a current dilemma, I think it does a disservice to them and doesn't really help.
This statement was never false.
|
|
|
|
|
|
The Grand Negus wrote:
If something is crappy, it should be opposed. Passionately. No man has to work on junk; he chooses to.
I completely agree with you on that.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Ahh... but the product is to be available to people independent of their storage choice. Not to force them in any direction. Say a large company like Oh... maybe FedEx, wanted to purchase our product. But they have 100s of thousands invested in their systems. Database and otherwise.
It would be in our best interest to support as many storage mechanisms as possible to ensure sales.
What you are proposing is not very realistic. Expecting customers to invest more money into third party software when they already have software of their own, isn't reasonable. You are asking them to throw away money. I don't know of any company that is willing to do that.
This statement was never false.
|
|
|
|
|
I would recommend keeping the object neutral with regard to source. So seperate out the population mechanism such that it can come from multiple datasources if you have that requirement. I wouldn't couple it with a dataset for instance. For instance we have to support loading from an app server, oracle, or mssql.
As far as whether it should be flyweight or not really has more to do with your application.
Even for the flyweight pattern I embed some transformations. Like say dates, int verses string, etc. For bulk operations I usually put together a helper class that knows how to use them. Which would usually be tied to some other mechanism like a database, or app server.
Is that kinda what you were looking for? I guess it depends on what you mean by data manipulation.
This statement was never false.
|
|
|
|
|
Hi Chris,
I've never really liked using datasets as a whole, but i do find the Tables and Adapters immensley useful stand alone (Although there is exactly zero chance of a DB change).
By Manipulation, i mean the functions that wrap execution of the SQL.
As a concrete example, i've tried it a few ways, but i'll go over them briefly and see if that clarifies anything.
1) An Account data object that contains just the fields, and an account manager object that can handle inserting, updating, enabling / disabling etc.
2) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc.
3) An account data object with the fields AND the functions for handling inserting, updating, enabling / disabling etc, with a support class which has the same functions (like example 1) and is required inside the data object for the data object's functions to work. Basicaly the functions proxy to the internal objects method calls.
I've tried all of them, and unfortunately, its left a bit of a mess in some of my code as i couldn't make up my mind what was the best way to go about it. I lean towards option 1, but think that 3 has some potential if done right.
T
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I would opt for number 1.
It leaves the data objects light weight in case you need to marshall them, or bind them to a web page etc. And in the case where maybe the database itself won't change, the schema might, and if you need to handle that case, then the places where the data objects are bound to controls etc, nothing has to change. You just change it in the data layer in the helper class.
[edit]
I usually use DataReaders and populate a custom collection instead of DataTables and DataAdapters. But the DataTable is nice if you need a filtered view in addition to the standard one.
[/edit]
This statement was never false.
|
|
|
|
|
Hi Chris,
Thanks for that, i think that's pretty much what i ended doing, using the DataRow as a data object, and the DataAdapter as the actual SQL wrapper.
I would be happy to use a DataReader, but find that i'd have to write reems of code to support it, and generate the queries and parameters etc. I'm guessing you use some kind of code generator for generating your parameterised SQL / Stored Procs? Did you write your own or go 3rd party?
If you wrote your own, How do you enforce field constraints (i.e. max string length 40) in the data object? Similar to the way a data row does.
If you went with the 3rd party route, what would you recommend?
Cheers Tris
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Alot of coding.
My system is on the mobile device. PocketPC. So, for my application I also have to generate the database. So I use a set of table descriptions that define the database to populate the business objects with. I use a table description to generate the select sql then populate the businss object from a reader into a generic collection. Validation of data is done at the form level. Since most of my processing derives from the user and the UI. Type constraints haven't really affected me much.. yet. I don't enforce anything in the data object. Its all either in the UI or in the DB.
This statement was never false.
|
|
|
|
|
I suppose what drives me nuts is when i forget enforcing on the front end, that gets dumped to an BO, and then on inserting into the DB, the data is out of range and the app falls over. Makes it a mission to figure out where it went wrong, which would be when the value was set.
They use a truncation method where i am atm, which drives me up the wall because there's NO length checking anywhere.
><
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
I have to develop specifications for a variety of integration architectures - mainly services based and using Message Queues, BizTalk and web services.
Previously, I was lucky enough to just do the dev work, if the specs were crappy, any number of e-mails would solve the problem. On the current project, specs have to be perfect.
Anyone know where I can get hold of the best, silver bullet template or a sample of an awesome spec? I am less interested in the boiler plate (doc distr. signoff lists etc).
Cheers
|
|
|
|
|
|
 Did you ... wait, nevermind.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Design and Architecture.
You may choose to associate your food with your waste.
But isn't this a gross simplification and a crude attempt to show a fallacy in object orientation?
Who would have a base category of "hinged device with hole"? No one. I'm sure you can come up with a better case if you really want to contest object oriented architectures.
You do realize that the natural world follows an object oriented paradigm?
Biology is a wonderful case for objects inheriting from base classes. Why do all felines look like cats? Why do all mammals have similarites? Why does plant life follow this same pattern of inheritance? And if it works so well for the natural world, why is it so flawed for this virtual one?
This statement was never false.
|
|
|
|
|
Actually it does happen in the real world, the defects are carried through the dna.
If your cat is screwed up, then its likely that its descendents will be screwed up. I think your holding to to strict of an interpretation. And the argument is still weak that object orientation isn't valuable in our virtual world.
The Grand Negus wrote: This is not the case when, for example, your program screws up a DLL that my program is sharing, etc.
That can only happen if my program recompiles the dll. Give me a break. Sheesh.
The Grand Negus wrote: Another reason that it works in real life is that plants and animals are living beings that do things on their own; most programs are more like tools that are used to do things - the procedural paradigm is more appropriate in these cases.
This is your opinion. And not necessarily shared by all. To make a blanket statement of authority isn't valid in this case.
This statement was never false.
|
|
|
|
|
|
We were discussing inheritance, not library linking. I statically link my dlls. In C++ I'd statically link the MFC dll. So, I wasn't prone to that. Only in the case of some third party dlls for imaging did I have to deal with it, and then I deployed the dll locally so any overwrites didn't effect me.
The Grand Negus wrote: It's not my personal opinion
It is your personal opinion that procedural programming is the better fit.
The Grand Negus wrote: If you can't (or won't) see that, then once again, I can't help you.
Why do you insist that I need help with this. We disagree on the value of object oriented architectures. Apparently I can see beauty there where you don't. I can also see beauty in procedural programming, but its a case by case basis. In fact, for true encapsulation you need a mix. The algorithms should be seperated from the data when possible. So, whatever. Sounds like Josh was correct that you are always coming from a perspective of guiding the youngling to your truth. And for the record, I'm 38. So, now you can condescend as to my lack of experience compared to yours within this physical episode.
This statement was never false.
|
|
|
|
|
The Grand Negus wrote: Granted. But (in my mind) the two are examples of a similar mistake. There's a significant practical difference, in both method and result, between a programmer who (a) extends an existing class hierarchy to make a new program, and one who (b) copies some existing code, deletes what he doesn't want, and adds in his new stuff. The question, then, from a biological point of view is this: when God makes dogs of both the poodle and the collie variety, are His methods closer to (a) or (b)?
A. Extends the dog class with variations that stem far back in the tree. This is where overloading as opposed to overriding would come into place (b). You would for the methods that you wish to dispose of, overload the method with either a new one, or an empty one.
And, as you say, in your mind. Again, we're getting back to opinion. I really think that a blended approach holds more value than either one standing alone.
The Grand Negus wrote: I'm saying it's an all-but-obvious conclusion that most logical thinkers would share.
Which is still your opinion. 
The Grand Negus wrote: That doesn't sound very object-oriented!
Actually it is. Read some literature on the developments of the paradigm. Of course, I would expect this response since you look to be biased against it.
The Grand Negus wrote: Yes; that, currently, is both my mission and my goal. See my profile here; I make no bones about it.
Well, in this case, we have a differing opinion on the merits of object oriented architectures. That's it. So, I don't see how you can lead me to the light here, since I find value in both procedural and object oriented approaches. This position you hold could very well be blinding you, you know?
The Grand Negus wrote: Thanks for the info, but it doesn't change much. I already knew you weren't suffering from the "arrogance of youth"!
Fair enough.
This statement was never false.
|
|
|
|
|
The Grand Negus wrote: In any case, from a human programmer perspective, (b) is a significantly easier approach because you have to keep much less in your head; things are what they are, period.
Not in my experience and this is precisely why I endorse an object oriented architecture. I've found value in it.
The Grand Negus wrote: Developments of a paradigm that deny the basic tenents of the original paradigm are not developments at all - they are admissions that the original paradigm was simply wrong, which has been my contention since the object oriented approach was invented and popularized by biologist/programmer "everything is an object" Alan Kay. I've lived through this kind of thing once already: the apparent advantage of hierarchical and network databases that fail to live up to their promise and eventually disappear in the light of the simpler relational model.
The basic tenents of the original was fledgling at best. And it was misunderstood in my opinion to mean that encapsulation includes every possible operation. For this reason the string comparison methods for CString in MFC are outside the class structure. Just procedural methods.
I don't agree that everything is an object, and that's been one of my objections with C# and .NET is that they take that approach, albeit catering to the needs of some procedural through the introduction of static classes, which are really just object like containers of procedural functions.
You won't win this argument with me, as its too subjective. I enjoy architecting with objects. I truly enjoy it.
The Grand Negus wrote:
I might think so if I didn't from time to time re-visit the alternative approaches to see if I had missed something. So far - after several of these re-visits - I still see very little benefit (and much unnecessary confusion) in the object-oriented approach. Really. I've coded the same non-trivial applications both ways and the object-oriented approach adds nothing but unnecessarily complexity and more machinery. See, for example, the discussion under point (2) in this[^] thread.
And that's certainly valid for how your mind works when designing systems. My mind works better with a blend of object architecture and procedural. Each does have a place.
This statement was never false.
|
|
|
|
|
|
As far as i can tell, the difference between a Procedural program and an object, is that Procedural sub programs have a single Method entrance with a large parameter list / block and internal branching, wheras an object can expose properties and a number of methods depending on the requirements, so the branching would occur on the level above.
Procedural Program - A set of methods with a central repsitory of values.
Object - A Set of methods with a central repository of values.
As for re-using code by copying functions, you're still fixing something that isn't broke, and an object that already works, works.
If someone changes your Sub Programs, and it breaks, you're still stuck with the same problem as someone breaking your Dll, so it's kind of a moot point. Software is software, in many ways it compares to real life, but it is still a non tangiable platform and the information age caveats apply.
The Grand Negus wrote: This is exactly what I mean by unnecessary complexity. First, they adopt a "pure" object approach and then, when they can see that it isn't quite working, they add something to simulate what they already had before they went with the objects. Schlepps.
I think that's the wrong way round, they static members came first, then objects.
That's just my two cents, but then.... What would i know.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
The Grand Negus wrote: Not in the "pure" object approach invented and popularized by Alan Kay. His first pronouncement on the subject being: "Everything is an object."
A key component, maybe the component, of object oriented programming for Alan Kay was message passing. Keeping that in mind, let's look at your oven example:
The Grand Negus wrote: The difference is that the procedural approach separates data and process: nouns over there, verbs over here. Cookies there, ovens there, baking something that the (implied) cook does with cookies and ovens here.
The object approach makes the processes part of the data: methods inside objects. Cookies there, ovens there, baking a method inside the cookie which somehow bakes itself. Or maybe inside the oven. Who knows? And what happened to the cook?
Well, my take on that would be that the aforementioned objects would send messages to each other. So we have an Oven that takes a Cookie. The Cookie is placed in the Oven by a Cook. The Cook sends a message to the Oven to bake at 350 degrees for 30 minutes. The Oven sends messages to the Cookie so that it changes as a result of the baking. When the Oven is done, it sends a message to the Cook that it is finished baking. And so on...
If I were implementing this in C#, I'd create an interface representing anything that can be baked; the Cookie class would implement this interface. That way the Oven doesn't have to know it's baking a Cookie, just that it has a "bakeable" object that it can send messages to.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
