|
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
|
|
|
|
|
virang_21 wrote: I inherited one project which has taken n-tier architectureKISS very seriously.
FTFY
|
|
|
|
|
ROFL...the same thing is performed by my TL
because our MD told to do it like that...
n we have to do like that without asking any ques
|
|
|
|
|
Couldn't resist adding some "Community Content" on what I found looking through Microsoft documentation.
=========================================
"layoutRect
RectangleF structure that specifies the layout rectangle for the string."
What an inane comment! So layoutRect specifies the layout rectangle! Who wouldda thunk?? What would we do without Microsoft to point out the obvious, while not giving a goddamn clue HOW a layout rectangle is relevant to the goddamn measurement!
It's idiotic comments like this that make Microsoft "help" the butt of jokes!
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
|
|
|
|
|
I remember a time some 15 years back when I was asked to implement some OLE2 features in our application (i. e. some views on Excel tables, both for entering and reading data). I looked up official documentation of OLE, but pretty much the only information it turned up was a pointer to the documentation of the Excel Automation Interface. This documentation looked something like this:
SetViewRectangle(Variant, Variant, Variant, Variant)
And that was it. No explanation of the function, or even argument names to indicate which is which! While the purpose was halfway clear from the function's name, I had no idea about the type and unit of the parameters, or whether it was top left x/y, bottom right x/y, or bottom left, top right, or maybe bottom right plus width and height? And that was the easy part, at least there was only a small number of possible ways.
The problem was that the documentation was like that for Every. Single. Function.
Fortunately that wasn't the only available documentation: there were in fact some quite useful books out there, just none by MS. But even those books didn't help when I migrated the application from Win NT to Win95, and found the effect of that function to be totally changed! I had to trial-and-error all over again to find the correct use of the function 
|
|
|
|
|
I've gotten to the point where I simply exclude any results from MSDN. It's worthless. I think the thing I hate the most is their "samples" which generally don't compile and more often than not have absolutely no relevance to what you're looking up. My favorite though is when you hit F1 over a method of a .net class like say Page.LoadControl and instead of outlining the parameters for LoadControl instead it just coughs up the general Call() help article. Because I was unaware that I was calling a function? Bastards!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
