|
Take my advice: Don't make yourself look worse than you already have.
|
|
|
|
|
Eddy Vluggen wrote: What you implied is that this information (whether the database-connection is opened or closed) should only be stored in the database.
That's not really what's meant by stateless design. 
I'd happily agree with you that any information stored anywhere IS "state" but going by this definition we'd be talking about information-free information systems, and I suspect they'd be useless.
What people actually mean when they speak of stateless is that the object instances themselves are stateless. There are no instance members. But there are method parameters and local variables, and they live on the stack. (If they are references to other objects, the objects themselves of course live on the heap. But every reference to them will be on the stack.) This leads to two properties which are sometimes desireable: You can't corrupt the heap in such a way that it affects more than one thread. A service for instance may fail under some condition, but this can't leave the server itself corrupted and subsequent requests still have a chance of succeeding. Secondly, it means the same "objects" can be shared among many threads, because they use the stack of each thread to store all the state they manipulate.
Lest you now become a fan, let me just add this: Stateless design also means throwing OOP out the window! Some will argue on this point, but here's my take. What really defines OOP is 3 things: Encapsulation. Inheritance. Polymorphism. But stateless implies you are creating "objects" that really are nothing more than a bunch of routines. And although you still have inheritance and polymorphism to play with, you can't put them to really good use, because you no longer have any objects, just mini-libraries of routines and subroutines!
Personally, I consider encapsulation the far most powerful - and least understood - aspect of object-oriented programming. It is what makes it object-oriented! You cannot model stuff as an object if you can't encapsulate. You could still do it without inheritance or polymorphism, though they are both *very* useful and powerful concepts. The most I would ever consider using stateless architecture for would be a small part of a server. This would ensure this part couldn't get corrupted. Then I'd make everything else properly object-oriented and build capability to "reset" the state into it. Hence the service could sort of "reboot" in case of trouble, and I could still program the vast majority of the system properly!
|
|
|
|
|
dojohansen wrote: What people actually mean when they speak of stateless is that the object instances themselves are stateless. There are no instance members.
This must be theoretical; I don't see this work with static (shared) members.
It's a nice explanation, but at this point, there's not much I can actually do with it 
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Actually I made a mistake; correct would be no instance *state*, i.e. no instance fields, only local variables and method parameters.
But it sure can work also with only static methods, though in that case you of course *also* lose the ability to use polymorphy.
Note that this doesn't imply there should be any static fields. They too would live on the heap and represent shared state.
Come to think of it, "isolated state" or "local state" would actually be better names for this type of architecture than "stateless". And again, personally I'm no fan of the beast.
|
|
|
|
|
dojohansen wrote: correct would be no instance *state*, i.e. no instance fields, only local variables and method parameters.
Sounds like a functional language. Something similar to F#?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Now you're just teasing me...?
It is nothing like a functional language. It's plain old procedural code. And you can of course write procedural code in C#, in methods in classes. But that doesn't make it OOP.
|
|
|
|
|
dojohansen wrote: Now you're just teasing me...?
Partly; F# is a functional language, seemed to map to having everything in a function.
dojohansen wrote: It's plain old procedural code.
In that case, I wrote a lot of those applications, in AMOS Basic. Somehow, that one seems to fit the previous description less than F#.
It became a mess quite quickly when your app grows larger. The best thing since sliced bread was the idea to group 'em. The idea that the local variables could be shared among that group was brilliant; took a lot of repeating parameters out of the procedures.
Lots of people still program in a procedural way in the new OO-environment, simply because it's easier to understand. And given recursion, you could still kill the stack.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
CsTreval wrote: You never heard of stateless architecture?
I have. I have used it. It however is limited to very specific applications and your original post did not make it clear what you are doing.
Additionally stateless architecture has little to do with object creation and much more to do with how data is used within objects.
I can create a stateless architecture in C (which has no objects) using global variables (which exist for the lifetime of the application.)
And MORE importantly efficiency has nothing to to with correct implementation. I can create very efficient stateful code which is incorrect because it is supposed to be stateless.
|
|
|
|
|
Sorry to say this, but the OP wasn't asking about stateless architecture.
|
|
|
|
|
I am hopeful that your question is confused rather than you and or whoever is providing this information to you.
Retrieving data from a database is a relatively expensive operation. Period. Doesn't matter why you do it. That however doesn't mean that you can retrieve it once only. The business needs drive in what way it can be retrieved.
You put database code in a database layer because that has multiple benefits. You don't put database code outside the database layer because doing that completely violates the point of having the database layer in the first place.
And notice that nothing in the above has anything to do with stateful or stateless.
CsTreval wrote: For example, I once put an object reference inside a Hibernate DAO class and I was told that this was incorrect because DAO classes are not supposed to have state. State should be inside the 'service layer'.
As a general statement that is nonsense.
Implementing code for real businesses is not clean. You attempt to create well crafted code but only to the extent that it makes sense to meet the needs of the business.
Other than that I can only suppose that you did something really wrong in terms of service separation and database layer separation and that point was being emphasized.
The database layer should to database stuff. The service layer should do service layer stuff. Again normally, not exclusively.
And note that none of this has anything to to with the general topic of object creation. Nor with performance.
CsTreval wrote: Create it once there and let the rest of the application access its instance later. Do not create this instance upon every call.
As stated generally nonsense.
It depends on what the object does. I don't need to retrieve the database connection string on every call. There is however no point in not creating a StringBuilder on every call.
|
|
|
|
|
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not.
Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
This is the perfect place for this question, so don't worry about it.
To answer your question, for custom builds for clients, we use source control to manage this. Basically, we have a branching strategy where these clients are branched off our main development trunk. Appropriate changes from the trunk can be merged down to those branches as appropriate. The process is a lot more involved than this, but that's the basic level (because we have branches off branches, to deal with test phases, etc, and release branches - it all sounds horrendously complicated, but our CI procedures make it a complete breeze).
|
|
|
|
|
I understand. It does indeed sound complicated but thinking enough about it, I can see how it really isn't so painful. Haha. Thank you all for the input! I use Git for source control, although I am a standalone developer, both independently at home and at work. I'm the only developer. But I've read about the many benefits of source control, even if you're a single developer. And I have seen truth to it all. Haha. But I'll look into branching more, I've seen the term in Git, just never took the time to learn. Thanks again!
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Depends on what the needs are.
Some possibilities exist with many variations within each.
- Create abstraction layers. Customer specific code replaces the default implementation.
- Run time meta data. The application functions differently based on data that drives the application. This can include but is not limited to run time scripting.
- Distinct application layers. A customer choice replaces a default layer.
- Customer overlays. Customer software is created which is part of a build step which either replaces source or binary sources with customer specific idioms.
- Extract customer choices and push them back into the main code base.
|
|
|
|
|
A custom build is necessarily a different BUILD, so things like run-time metadata is out the window. 
|
|
|
|
|
Source control is by far the easiest way to do this. It gives several benefits, to name a few:
Reverse Integration (fix a bug in one, move it everywhere)
Single point of backup (Developers don't have all the code on their machine)
Versioning
Simple version differencing
Many more. Once you start using something like TFS you'll never go back.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
Expert Coming wrote: Source control is by far the easiest way to do this
That doesn't seem to have anything to do with the OP.
The OP has a single product to which customizations must be done to support different customers. They are already aware of how to do that using completely different code bases (which is the only way in which source control can have an impact.) What they want is ideas on how to do that differently.
|
|
|
|
|
The last sentence in the OP is what I was replying to. He asked if this is usually done in SCC, to which my response was that it is the easiest way.
I did however fail to provide specifics which I should have done.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
|
|
|
|
|
I've been using jQuery quite a bit lately, and I've enjoyed how easily it makes navigating and manipulating the DOM.
When I think of other areas of my code, I sometimes wistfully wish it was as easily to mainpulate the data there as it is to manipulate the DOM with jQuery. This makes me wonder if I'm missing an abstraction. The DOM is really a tree at the heart of it. So maybe, where it makes sense, I could attempt to model the data in the domains I work in as trees. Then use a domain specific language to manipulate those trees.
|
|
|
|
|
Once one learns to use a hammer and practices with it quit a bit it is easy and fast to use it to join lumber in any number of different ways.
That doesn't mean it is a replacement for a drill.
And it certainly doesn't mean that one should use it when making a cake.
|
|
|
|
|
"Once one learns to use a hammer ... it certainly doesn't mean that one should use it when making a cake." 
/ravi
|
|
|
|
|
Hi,
we have a .Net based application (C#, VB) and we want to integrate basic document managment functions for the documents we create in our application.
We need to provide some functions for the users of our appication to manage the documents created within our documentation.
We don't want to have a stand alone DMS, we rather like to integrate a library/framework with basic structure and functions we can use in our code.
Like versioning, Check-In/Out mechanism.
I searched via google for quite a time but I have not found something. Maybe I don't use the best keywords.
I hope anyone knows a library on the market.
Thanks a lot! 
Edited: given more Informations and correct typing
modified 17-Sep-12 6:22am.
|
|
|
|
|
Try CVS[^] or SVN[^].
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for your suggestion.
I think you missunderstood my question, so I edited my question to make it more clear.
We do not need to manage our own source code, we use mercurial for it.
I am searching for a DLL with we include in our c#/vb project. We need to link the managed documents to data in the customerdatabase.
We need to have meta-data /attributes stored with the document and a right managment within, also searching mechanism.
|
|
|
|
|
You're looking for an awfull lot of functionality, I doubt that you can simply add a reference and be done with it.
Your best bet would be to Google for an "open source DMS", and to modify it to suit your requirements.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
