N-Tier architecture
-
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...:mad:
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
-
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...:mad:
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."
-
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."
-
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...:mad:
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
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...:mad:
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
-
Exactly... :(
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
-
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...:mad:
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
virang_21 wrote:
I inherited one project which has taken n-tier architectureKISS very seriously.
FTFY ;P
-
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...:mad:
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
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
-
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...:mad:
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!
-
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