|
I go for #3.
from DB to OO, check http://www.mygenerationsoftware.com. My Number 1 choice.
|
|
|
|
|
opps
this is an application ...
i need to know the algos ....
if there are a documentation or something like that ...
thanks a lot
|
|
|
|
|
What you describe is a tree. Depending on the direction you want to go in the tree you should choose 2 or 3: 2 if you go from the root to leafs (you have the house and you want the rooms) or both ways (previous + you know the room and want to find the house it belongs). Choise 3 is more complete and memory used to keep the pointer to house is small 4B.
Usualy I do like this: a row in a table contains all the members of a class - each row = object; procedures that insert/update/delete in the database are methods of the class, each method calling corresponding stored procedure. Columns (members of classes) are accessed (read/write) through properties or functions offering a good consistency check even from the input of data.
|
|
|
|
|
Hi,
I´m developing a .NET 2.0 library (dll) which basically is a stamp clock that logs working time and prints job specifications. The application separates UI from logic by a library design approach. I plan to implement both a Windows Form UI and a AJAX UI on the library.
The question: What is a good design regarding how to store the logged time entries/data? Shall I store the data in a mdf database or XML files or make an interface an let the application that make use of the library (UI) implement the database interface to enable custom database usage (by doing this every implementation a database setup has to be carried out = bad)?
I know this depends on the purpose and usage. Is the mdf approach a good way to store data in both a webapplication and a desktop app? I find this a bit confusing. ^_^
Thanx in advance
regards
/Christoffer
|
|
|
|
|
http://en.wikipedia.org/wiki/Model-view-controller[^]
Model
The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
led mike
|
|
|
|
|
Hi all,
i want to study internals of fat file system.
so for that purpose which book i should use as an reference book.
just what
"The design of unix operating system (Maurice J Bach)"
does to understand the unix file sysetm.
Is there any such book by which i would be able to understand the fat file system.
If anyone know's please tell me.
i want to create a file system driver for fat fs.
Thanks and regards
Harshal shete
|
|
|
|
|
There was a book which presented a DOS compatible operating system, but I think it's out of print. However, you could look here[^] where you can download a copy of the FAT32 specification from Microsoft.
Steve S
Developer for hire
|
|
|
|
|
I'm working on a VB application that may resemble MS Money. You have a toolbar at the top and a spine on the left that have specific tasks that may be performed for each main function. For example, on the toolbar there is a "Customers" button. Once clicked, the spine on the left will have "customer" specific tasks (i.e., Add New, Select, Reports, Open Issues, etc.... To the right will be the results of whatever task they select from the spine. Since any of these tasks may involve several pages or forms, I thought about using groupboxes or panes for each of the task; however the maintenance of all those controls could be overwhelming.
So I guess my questions is, if you think of how MS Money functions, what is the best approach for designing a rich client application? Possibly using customer controls for each function? Would I group them all in one main "Customer" control??
Any help (VB) would be appreciated.
Bob
|
|
|
|
|
Bob,
Assuming your using VB.NET 2005.
There are tons of techniques. Using a MDI approach would be easy also. You could define a single class for controlling which one is currently visible.
Another approach, is to use multiple Panels on the same form. Hiding each one but the current one.
You can optionally use a Tab control, only showing a single tab at a time.
Of course, I'm not clear on how MS Money does it. But there are also docking controls like the split panel control.
If you are not using VB.NET 2005, instead you are using VB6. Then you'll have to do a little bit more coding, and some of the controls listed are not available in VB6.
In VB6, you can use multiple Panel controls. Set the Left Property of the ones you want to hide to -10000. This moves it completely off the form. You can swap them in and out by setting their corresponding Left property to the setting that makes them visible.
Although, I've created some fairly complex applications in VB6. I've been using VB.NET for quite sometime now.
Hope this helps!
~ CodeDoctor ~
|
|
|
|
|
hai,
i want to develope asp.net web project.any tools to design the project specs,Preparing DSD.
Thanks and regards,
surendra
|
|
|
|
|
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself.
The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU.
The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs.
Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Why are you hard-coding the items? Wouldn't it be better to create a database?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
What makes you think he is not using database? Mapping DB records on classes is nothing strange...
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
Roger Wright wrote: Can someone among you geniuses suggest a logical class heirachy for this mess?
It would take more than a "genius" to do so because there is no logical hierarchical model for something that isn't, inherently, hierarchical. It isn't a "mess"; it's just not hierarchical.
|
|
|
|
|
- Do you have an existing GIS ?
- Do you model/maintain phase info ?
- Do you model secondary runs from transformer to meter ?
- Do you model transmission (to subs)
(ok, only effect the fields, but i'm curious  )
You will not want to break down the tables or class' beyond the type level.
e.g.
InvItem
|__ Fuse
|__ Transformer
| |__ 1 phase (optional)
| |__ 3 phase ('')
|__ Capacitor
|__ Switch
|__ ...
Some of the elec inv systems i've seen didn't even maintained separate tables for facility types.
It was one big table with InvId, vendor, manuf., manuf sku, price, price date, (elec util) sku, description, ...
Decription held "40A fuse", ...
You will make life easier if you match the facility table break down that you use in you GIS (assuming you have a GIS, assuming you don't want to throw all inv items into one table).
The inv system doesn't (generally) care about details like phases, amps, voltage, ... that should all be in the GIS table (that's why you can throw all that info into a inv desc field).
The GIS table should just contain the InvId (unique for vendor/manuf/manuf sku) and optionally the (elec util) SKU (read-only in GIS, to validate InvId), plus the detail info like phases, voltage, circuit, ohug, state, ... .
Of course going to the next level, you break out the detail info in the inv tables, and have the inv system tied to the GIS so that the GIS placement routines use the inv system to display validation tables for the digitizer to select from (then pull phase, ... from inv tables and copy into gis fields).
Once you have all this info you will want to gen std drawings e.g. std pole, std gang-switch (attachment for a pole), ... . This system can then be used by the eng to do quick designs and part/cost estimates. A full system includes things like how many man hrs it takes to install each part as well.
If i were coming to you guys as a consultant the system i would propose would depend LOT on what you already have (what GIS - what schema, do std drawing exist - what format, current inv data system/format, ...) ... and of course how much money you want to spend .
...cmk
Save the whales - collect the whole set
|
|
|
|
|
cmk wrote: Do you have an existing GIS ?
Yup, and we paid a bundle to collect it. Unfortunately, now that I've gained more understanding of the GIS schema the consultant created, I see that it was a crappy job, full of unused fields, duplicates, and unnecessary data.
cmk wrote: Do you model/maintain phase info ?
- Do you model secondary runs from transformer to meter ?
Not yet, though we collected conductor/structure data with the intent of one day modelling it. Ideally, the GIS geodatabase would be the ideal place to store details about structure and implementation, and a separate db would contain just stock and reordering info. The more important task is probably to clean up the mess in the GIS schema, but the priority from a business standpoint is to track and maintain adequate stocks of spare parts - two very different jobs.
The info in the GIS system should probably be treated as a super-inventory, with assemblies tracked as finished goods created from parts drawn from stores and tracked by the general inventory. We use RUS standard structures, with minor variations, for most of our network, and I have the standard drawings in AutoCAD format. Since the new AutoCAD 2007 adds the ability to link the data fields in a table to an external database, it should be fairly straightforward to generate up-to-date costs at the structure level for future construction using average costs from the inventory db. That would also, when coupled with accurate GIS data, give us current replacement costs for installed plant.
Hmmm... You've given me much to rethink - Thanks!
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Roger Wright wrote: full of unused fields, duplicates, and unnecessary data
I've worked with a dozen or so elec utilities, EVERY one had the same issues, as well as unfilled fields - which can be the most frustrating.
Roger Wright wrote: The more important task is probably to clean up the mess in the GIS schema
Another common phrase heard at utilities everyware. 
Roger Wright wrote: should probably be treated as a super-inventory
I view the GIS as the asset management system vs the inventory management system you're developing.
The main problem i've seen with IT systems developed in utilities is one that is forced on management. Usually the initial project is funded by capital funds and can be as big as needed, but after that any further work is funded by the yearly O&M budget which is much smaller. As a result they try to cram everything they can think of in the initial phase. Unfortunately after a year or so, upon reflection, it is obvious that a lot of things could have been done better, but now there are stuck with a bad design that they have to work around for the next 5yrs - at which point they replace the GIS again ... and so the cycle continues.
Roger Wright wrote: standard drawings in AutoCAD format
Also fairly common. As you mentioned it should be fairly easy to link these to a db. What you really want to go for though is having a design interface in the GIS that allows your engineers to place prelim plant and be able to query the standard drawings. This GIS interface would also give the eng the ability to select (by region or piece) the prelim plant and generate a BOM. What i'm trying to point out is that the acad-db combo is just a data source, it's useless on its own, you still need to design/develop the interface to it in a GIS design module. This design interface will likely be (should be) different than that used by the digitizers to place designed plant.
What GIS are you using (ArcInfo, Smallworld, AutoMap, Intergraph, ...) ?
If you have any questions, or want to bounce some ideas around feel free to post them or email me, i find all this stuff fascinating (well i guess i should, it's my job as well ).
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Correct me if I'm wrong, but you are looking to do something like this:
You have a collection of unique InventoryItems.
Each InventoryItem has an SKU associated with it.
You have a collection of manufacturers
You have a collection of vendors
A manufacturer has a collection of vendors associated with it.
A vendor has a collection of InventoryItems associated with it.
A manufacturer has a collection of InventoryItems associated with it.
The Overhead, Underground, etc. are just types of InventoryItems.
If this summary is correct, then we can go from there.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
That's about as far as I've got with it, and it's what I'm used to seeing in retail. But what cmk, above, suggests makes sense. I'm going to play with that approach for a bit and see where it takes me.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Hi all,
i m developing a ndis miniport driver.
in my miniport driver OS is able to enter into Driverentry function automatically after regtistration of the adapter in NSB_Init function.
in DriverEntry's initialize function, i activate a timer which reads from the hardware.
now this timer is able to read the data from hardware but i am nt able to bind it to the TCP/IP stuff.
i think there should be some binding issue.
i tried with "NdisBindProtocolsToAdapter", but it is not able to bind it
when i called "NdisGetAdapterNames" after that, i am able to get my adapter's name in that.
so if i say basic problem is that i am able to get the data in MAC layer but i am not able to bind it to tthe IP layer.
can you guys solve this?
if yes then kindly give me some clue about it.
thanks in advance.
Hardik 
|
|
|
|
|
Errm. This is the wrong forum. It's about application design and architecture.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hello All
I need to send email using Binary SOAP. I used DIME but i realised that
it only send attachment by binary soap, though my requirement is that i
need to send attachment AND the enter email attributes(user's and receipient
email, message, subject line). can anyone tell me how can i have this done and
which technique to use for sending all these attributes using Binary SOAP.
Ankit Sharma
|
|
|
|
|
Intro:
I am trying to design a triggered execution system where the developer implements trigger-modules that is loaded runtime and fires an event that the system can subscribe to.
The user uses an interface to the system where he can create new instances of triggers and specify the needed input to the selected trigger.
Example:
The developer implements a File Change trigger, that fires an event whenenver a user specified file changes.
This would require some input Fileobject and the possibility to save the last run date for the trigger.
When the user chooses the File Change trigger in the interface he should be prompted to input a file, which is then stored in the instance of the File Change trigger.
2nd Example:
A Calendar trigger. The user should be prompted to select a date in a calendar+ a time and the trigger would then fire the event on the specific datetime.
Question:
The interface is a thin client and does not know anything about the modules in compile time except the interface. So the question is - how do I design the module interfaces so the interface knows what information to ask the user for (and how) and insert the user input into the instance of the loaded trigger?
I have played around with HTML contained in the module, presenting it in the interface and catching the user input.... But so far not in a satisfactory way
(I hope this summary made sense )
Thanks in advance...
|
|
|
|
|
This article might be of some help. Razor Framework.[^]
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I am trying to write a layered app in vb 2005 .NET
I think on a 2 physical levels/tiers: host with a DB, and client (desktop), both not interconnected (except for internet)
Host: will contain the DB (SQLServer) , the Data Access Layer DAL, and a Web Service layer, WS_CH
desktop, will contain the application (winforms), and Business Logic layer BLL. The BLL will call the (remote) WS_CH, this will call the DAL and this will attack the DB. OK.
I will use a Data Transfer Object DTO to pass data up and down all the stream, from the UI to the DB and back. This DTO can be an untyped dataset, in which case all the assemblies involved (in fact, all I mentioned) will contain a reference to System.Data.
But.... what if I want the DTO to be a custom class, living in a independent assembly, and possibly hosted in the client. How will the host receive and handle a reference to that (remote) object.
Have I to place the DTO in the host (because from the client I know the URL and then I can reference it)?. If not, i suspect I have to use remoting technology, or activator, or reflection, or the new WCF in 3.0,... but I cannot find my way to that.....
Any hint, please? thx
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
