|
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[^]
|
|
|
|
|
Not sure why it needs to be open source and modified, as far as I read the requirements are pretty basic. Versioning and check-in/out appears to be all that's needed.
But I do agree that a DMS is probably the way to go and don't quite understand why the OP has decided a priori that they don't want that. After all, document management is the functionality they need...??
|
|
|
|
|
dojohansen wrote: After all, document management is the functionality they need...??
It sounds like it does, but without a response, we'll never know
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
NH71 wrote: We do not need to manage our own source code, we use mercurial for it.
That however doesn't alter the other suggestion of using a source control system. The source control system provides checkin/out of ANY file based product.
|
|
|
|
|
NH71 wrote: 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.
Based on this and your other posts this isn't going to be easy.
So far you have asked for
- Check in /out
- Versioning
- Rights management
- Document attributes, presumably associated with a user.
That would all need to come from somewhere. And it would need to be stored some where.
As per the other request a source control system would handle the first two requirements. But you would need to handle the second two yourself. And I expect that you have other unstated requirements as well.
Overall it suggests that you do in fact want a DMS.
|
|
|
|
|
I still relatively new to most things but in particular very new to design patterns and I'm struggling to pick a good pattern for a particular task.
I've chosen to do the Mandelbrot 'rite of passage' by trying to build a 'pluggable' class structure so that I learn more from this exercise than perhaps I otherwise would.
What I have right now looks like (I think) the strategy pattern with the builder pattern (I think) hidden in the constructors. I.e. I have an Imager class that has two members, both of which are of an Interface type. One interface is for the fractal set (mandelbrot, julia etc.) and provides a pluggable iteration / algorithm. The second is for a colouriser which provides a way to turn the results of the iteration into a colour. The set has a member that is an interface type, it is for the specific F(Zn) calculation in Zn+1 = F(Zn) + c. The colouriser also has one member that is an Interface type, it is for mapping the output of the colouriser to a specific colour. I think that is the strategy pattern? But I'm not certain (a) if it is, (b) if I've implemented it correctly or (c) if there's a better choice.
The Imager constructor can take a new set and a new colouriser, The set xcan take a new function and the colouriser can take a new mapper. I think that's builder?
Any help or guidance on a good choice for the job I described above would be very welcome as indeed would any help deciphering what I've already done!
Happy to provide code etc. as required to make sense of the mangled gibberish above.
Thanks,
Mike
|
|
|
|
|
Looks like your Imager class is general purpose enough and you've used IOC to provide the the smarts. Seems logical to me.
/ravi
|
|
|
|
|
I am beginning a basic shop floor control system for a client who currently consults giving advice on optimizing manufacturing processes. My problem is that he uses very broad and vague terminology in descriinbign requirements to me, and I would like, ideally, to consult some reference models or diagrams or such systems, but Google research is proving quite slow and not to fruitful.
For example, my client uses the term 'machine' for what I have found out could rather be called a 'work center', and has no term for what I have found out should be called a 'work center'. Adding additional tables required for a nice system design but don't feature in his paper design adds more challenge. What do I call the definition of 'the process done by a work center to produce a product (or BOM item)' etc.
|
|
|
|
|
There's no guarantee that the client is using accepted terminology. What you might want to do is to include a definitions section in your documentation that ties the terminology down; we've done this in the past and it's surprising how well it works when the client uses 6 or 7 terms to describe exactly the same thing.
|
|
|
|
|
Pete O'Hanlon wrote: There's no guarantee that the client is using accepted terminology.
Never mind a guarantee; there's hardly even a vague suggestion that he is using accepted terminology. I'm trying to find a nice taxonomy I can use for candidate terms we can agree on and move forward with.
I found Openbravo[^], an open source ERP system, which is very promising. Will look at it tonight.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
