|
|
Manfred, have you ever used the notification service, I know we have never had to implement it and I am curious.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I know we have never had to implement it and I am curious.
I have been exclusively doing backend database driven stuff often in high demand environments and the only 'need' I have ever seen for this is when some developer claims that it "could" happen. Analyzing actual business cases and actual usage has never demonstrated a need.
|
|
|
|
|
That has been my experience except I'm the developer so it has never happened, every now and then I have to slap a BA who suggests it to the users.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Indeed I always heard the rumors of SQL notification to subjugate LAN as RTS but caching one is like "fools gold".
|
|
|
|
|
Alok sharma ji wrote: 3. how does client A gets notification of SQL update by client B ;when both are viewing/working on same table. So the record can get an auto refresh or something like that.
That's usually not done; the normal way is to fetch the data and show the snapshot as it was on the moment of fetching. Updating "live" data moves the concurrency-problem from the database (where it was solved) into your app, where you need to solve it yourself.
Simple example; you're editing a record, and the boss is editing the same one - you press "update" first. Now, how would you update the bosses record? Change the text in the textbox while he is editing/typing?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
i think i will just put an edit lock for client 2 if client 1 is working on same table.
|
|
|
|
|
Alok sharma ji wrote: how does client A gets notification of SQL update by client B ;when both are viewing/working on same table.
That statement is a bit simple since it isn't a matter of working on the same table, since databases deal with that, but rather working on the same record (data) in the table. And that doesn't matter because it is very, very rare that there is an actual business case for that.
For example when a order center takes a customer order only one employee is taking the order. The customer is making the same order on two different phones lines.
|
|
|
|
|
Why are project files/classes organized by class type (Models folder, Repositories folder, Interfaces Folder), instead of business purpose (Account Objects, Employee Objects)?
I can understand storing reusable files in their own folder, but what about files that really only work when they are part of a unique and specific unit?
Organizing projects by class type seems like story left shoes in one room and right shoes in another room. You need a specific pair of shoes for them to work.
|
|
|
|
|
Mine aren't.
My are divided by function into separate projects:
Presentation (which may have multiple projects)
Business (Again, may well have multiple projects)
Utilities (ditto)
Data Access (normally just the one, but If I'm looking at multiple data sources, I'll probably break it that way as well)
How things are organised is up to you (or your company standards) - it's your project!
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
That's an interesting approach. What's the thinking behind that structure? Do you typically work with presenters alone, and then Data Access alone? Or do you usually work with a group of files from each project based on business process?
|
|
|
|
|
The thinking is that I can swap out my data access for a different datasource without affecting anything else in my application - or I can transport my business logic to a different machine, running Xamarin on an iPhone, or Android perhaps - and just provide the new presentation stuff. The less I have to change, the more reliable the whole should be.
What I work with depends on what I'm doing: I try to work on projects in isolation, with a tester module and only backtrack and make changes when it's clear they are needed.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
OMVB wrote: but what about files that really only work when they are part of a unique and
specific unit?
That would be unusual.
OMVB wrote: instead of business purpose
Because business needs very seldom devolve to a single class. Even a single business need seldom devolves to that. A single business need is more likely to be fulfilled by multiple classes interacting together.
And in designing for a business there are often groupings of classes based on their common nature that represent layers. Because they are similar they are kept together.
|
|
|
|
|
Instead of a technical structure like this:
>Models
>>AccountModel
>>ContactModel
>>HouseModel
>Repositories
>>AccountRepo
>>ContactRepo
>>HouseRepo
Why not organize the project like this?
>BusinessObjects
>>Accounts
>>>AccountModel
>>>AccountRepository
>>Contacts
>>>ContactModel
>>>ContactRepository
|
|
|
|
|
If that was the only level of interaction, that would be fine, but how about talking to the database? What about system configuration or personalisation? What about an account for a contact? How about address maintenance?
|
|
|
|
|
Would it make sense for the account/contact relationship be first established at the DB via a foreign key?
ContactID
AccountID (foreign key)
ContactFirstName
ContactLastName
Then use the Account model and repo to grab a list of accounts from an account table or view, then use the Contact Model and Repo to grab the contacts related to a specific account?
There would certainly be some classes that would fall into a "common" category that would get reused, such as a db connection class, personalization and system configuration.
However, it seems like organizing some classes based on Business/DB Entity would make more sense then hunting around two or more folders to edit closely coupled class files, when certain class files only work as a unit.
I am still trying to figure this out. 
|
|
|
|
|
You're cross cutting class responsibilities here. Don't think about what happens at the database level, think about what happens at the object level.
|
|
|
|
|
Hi,
A) In C# namespaces are purely logical sorting. So are the folders and files structure. This is all subjective. Make sure your API and structure is consistent so people know where to find stuff. That is it.
B) A project groups files, folders and resources and produces an assemblies/executable. This is where the tools introduce cons and pros regarding code structure. As an example what impact does visual studio and testing tools have on your code structure? (e.g. code generation when making a form introduce a certain file structure).
C) Your products need to be distributed, integrated, re-used, maintained/updated, etc. All this is about layering and splitting and thinking about dependencies. How well can you replace your logging functionality, add a new product platform or change a database dependency... and how do you keep the cost of making, testing and deploying the next feature as low as possible?
When you have a strategy for B) and C) you can go back to A) and make a logical decision. ½ a year later it might be that you would have preferred another logical decision, but at that time you stick with the old decision to avoid introducing new confusion. However, B) or C) might force you into re-ordering the code structure.
Kind Regards,
Keld Ølykke
|
|
|
|
|
OMVB wrote: Why not organize the project like this?
What part of my specific answer to that did you not understand?
|
|
|
|
|
I got the answer I needed, which isn't the one I was hoping for. The project will be for an application that creates a single assembly (client requirement). We have been looking at different structures to see how easily the typical C# developers could pick up the project and run with it, based on different file/folder structures.
There are a few instances where pairs or trios of file only work when all are in place. Similar to .ascx, .ascx.desinger, and .ascx.cs.
Its a good idea to test the waters before making these kinds of decision.
In general it appears C# devs are culturally inured to grouping files by technical purpose rather than business purpose, even if there is little reuse of object and the debugging worklfow would be much faster by having files grouped by business purpose.
Your answer was clear and its was VERY helpful! Thanks!
|
|
|
|
|
OMVB wrote: Why are project files/classes organized by class type (Models folder, Repositories folder, Interfaces Folder), instead of business purpose (Account Objects, Employee Objects)?
Because programmers work with projects and types, and not with the abstractions called "Account Object". A code-solution is not an exact model of the business, and there's usually more types in a library than business objects.
OMVB wrote: Organizing projects by class type seems like story left shoes in one room and right shoes in another room.
..Yes, in the same way that a car has wheels in the front as well as in the back, but in the storage-room you'll find them on the same heap.
They're also not organized by "class", but by "target" or "goal"; there's no models-folder in my private projects, but models go together so that it's easy to find if I need a specific one. No, we don't have all resources in the same folder, but the resources that are considered a single package are.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
i everyone,i have a problem.i wan to scan my local network to get information about all the devices inside like OS name,Ip adresse netmask and mac adresse to realise a topologie of my network.thanks
|
|
|
|
|
|
|
Amusingly, that article would been called a code dump under the current criteria and probably relegated to a tip, how things change.
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
