|
Önclick? That definitely sounds Turkish
I'm invincible, I can't be vinced
|
|
|
|
|
because i am Turkish I get it
|
|
|
|
|
I think it would be less misleading if the ReturnFalse function was instead named AbortAction or something closer to the intention.
I think it is better practise to name a function or method for it's intended purpose or meaning than for what it literally does. The intention/meaning and what the method actually does usually are the same, but there can be subtle differences and occasionally vast differences such as in this case.
Oh and a comment for the function would not go amiss either:
function AbortAction()
{
return false;
}
modified 29-Mar-12 16:14pm.
|
|
|
|
|
if (RegistryKeyExists()) {
} else {
CreateRegistryKey();
}
What should we do with such "programmers"?
|
|
|
|
|
|
You should commend them! Seriously, this is good work.
If you consider that most people touching code are idiots, it's always good to duplicate code around, so that if someone messes up one copy, only a small part of your app gets broken, rather then the whole thing.
|
|
|
|
|
Really? is this how you protect your code?
|
|
|
|
|
No - it's how he protects his job
|
|
|
|
|
I don't know if this is appropriate but it make sense
|
|
|
|
|
Yeah! Considering most people touching the code are idiots, we can be sure that they will mess up with something like SVN too.
Peace, ye fat guts!
|
|
|
|
|
You could ask copy shops in the neighbourhood if they have a vacancy...
|
|
|
|
|
You dont have to do anything. eventually the employer will promote them to "managers"
|
|
|
|
|
Sad but true.
Signature construction in progress. Sorry for the inconvenience.
|
|
|
|
|
However, once promoted to a manager they then make decisions on how all programmers should write their code. And they use their own code as a perfect example.
Had one manager who refused to let any developer rewrite the systems that the manager had written!!!
|
|
|
|
|
Shameel wrote: I am sure you misread. There is probably one variable just slightly different which would completely justify the duplication
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
I was thinking the exact same thing
|
|
|
|
|
Yeah, probably some string value somewhere contains an O instead of a 0
|
|
|
|
|
I inherited one project which has taken n-tier architecture very seriously. First of all it is using WCF by adding reference to the WCF service class directly. There is no service. It is used as a simple class reference. ( Big Fail !!! )
The thing that is really pissing me off is the level of tiers created within the project that has no relevance whatsoever.
UI => BL.Service => BL => DAL=> Database
In this chain all BL.Service Classes and BL classes do is to call methods from its corresponding class above. No logic whatsoever in those one. Just call the method and return value.
UI
dsPClayL = _IWCFPClayL.GetItemInfo(ConfigurationManager.AppSettings["FacilityId"].ToString(), string.Empty);
BL.Service
public DataSet GetItemInfo(string strFaciId, string flag)
{
return _objBLPClayL.GetItemInfo(strFaciId, flag );
}
BL
public DataSet GetItemInfo(string strFaciId , string flag)
{
return _objDLPClayL.GetItemInfo(strFaciId, flag);
}
DAL
This is the one where it connect to database and process request.
Why in the world do you need BL.Service and BL tiers when all it is doing is calling method in DAL...
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
What, so you're saying there are all these tiers but the business logic is smashed into the UI?
"You get that on the big jobs."
|
|
|
|
|
Exactly...
Zen and the art of software maintenance : rm -rf *
Math is like love : a simple idea but it can get complicated.
|
|
|
|
|
Seems to be a 'Flat Tire' architecture.
|
|
|
|
|
Like the universe... it's n-dimensional and folded... somehow
(yes|no|maybe)*
|
|
|
|
|
virang_21 wrote: Why in the world do you need BL.Service and BL tiers when all it is doing is
calling method in DAL...
I think the same when I have to write a method like this in the application logic. To my defense: Most methods do a little more than that, but there are cases where you simply want to have some data without any great rules or conditions.
It looks like the developer fell into one trap probably everybody sooner or later falls into. A service may not take any input without checking it for validity, checking all applicable rules and possible also some technical requirements. This clearly is the job of the application logic and should be implemented in that layer.
Now we can build a 'dumb' frontend or client that just sends requests to the application logic and reports back whatever answers it gets. This works, but for the user this is less than perfect. A user interface should clearly show the user's options at any time and not blindly send off requests and wait for the application logic to grant or deny them.
In order to do that, the frontend or client must replicate the rule and error checking of the application logic to know which options must be enabled or disabled. Avoiding this kind of redundancy is not as easy as it appears. Solving this problem by moving the application logic into the frontend of course is no good solution, but it looks a little like the man who wrote this application made the wrong choice between two evils.
I'm invincible, I can't be vinced
|
|
|
|
|
I think the validation code can be separated. If we were able to somehow move the validation code of a function/service into another class/component, we will be able to reuse that class/component in multiple layers. You only have to write once, then use it anywhere.
Having said that, this might not be possible for all scenarios, but at least simple validations--e.g.:Credit card no should only contain numerics--can be separated.
Peace, ye fat guts!
|
|
|
|
|
A good candidate for that would be the data object itself. Just to take another example than simple validation: Let's say we have the common case that we need to store a password, which should be salted and hashed for security reasons. Why not put the method to do that into the data object? This way it can be ensured that the salting and hashing is done every time the password field of the data object is set. And this method can also be called to hash the string entered during login and then compare it to the value stored in the data object.
This may be contrary to the dogma that data objects are supposed to be simple containers for the data only, but in object oriented design it makes sense when an object has methods or properties to validate its state or make changes to its state.
I'm invincible, I can't be vinced
|
|
|
|