Use of large Business Objects with fewer properties [on hold]
I have a large Business Objects let's say having 50 properties. Now for a method I need only 5-10 properties. So is it good idea to use the same large object in that method or create a new BO with fewer properties.
c#
asked Dec 27 at 13:16
Ganesh Agrawal
215
put on hold as primarily opinion-based by fredrik, Ian Kemp, TrueWill, mason, Daniel A. White Dec 27 at 14:24
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I have a large Business Objects let's say having 50 properties. Now for a method I need only 5-10 properties. So is it good idea to use the same large object in that method or create a new BO with fewer properties.
c#
asked Dec 27 at 13:16
Ganesh Agrawal
215
put on hold as primarily opinion-based by fredrik, Ian Kemp, TrueWill, mason, Daniel A. White Dec 27 at 14:24
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
3
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, aCarobject wouldn't need have properties for every single component. You could break the engine components into a separateEngineobject, which exists in aCar. Then you could pass just do something likeTheMethod(yourCar.Engine)rather than passing an entireCarand accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.
– Broots Waymb
Dec 27 at 14:16
add a comment |
I have a large Business Objects let's say having 50 properties. Now for a method I need only 5-10 properties. So is it good idea to use the same large object in that method or create a new BO with fewer properties.
c#
asked Dec 27 at 13:16
Ganesh Agrawal
215
I have a large Business Objects let's say having 50 properties. Now for a method I need only 5-10 properties. So is it good idea to use the same large object in that method or create a new BO with fewer properties.
c#
c#
asked Dec 27 at 13:16
Ganesh Agrawal
215
asked Dec 27 at 13:16
Ganesh Agrawal
215
asked Dec 27 at 13:16
Ganesh Agrawal
215
asked Dec 27 at 13:16
Ganesh Agrawal
215
asked Dec 27 at 13:16
Ganesh Agrawal
215
215
put on hold as primarily opinion-based by fredrik, Ian Kemp, TrueWill, mason, Daniel A. White Dec 27 at 14:24
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as primarily opinion-based by fredrik, Ian Kemp, TrueWill, mason, Daniel A. White Dec 27 at 14:24
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
3
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, aCarobject wouldn't need have properties for every single component. You could break the engine components into a separateEngineobject, which exists in aCar. Then you could pass just do something likeTheMethod(yourCar.Engine)rather than passing an entireCarand accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.
– Broots Waymb
Dec 27 at 14:16
add a comment |
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
3
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, aCarobject wouldn't need have properties for every single component. You could break the engine components into a separateEngineobject, which exists in aCar. Then you could pass just do something likeTheMethod(yourCar.Engine)rather than passing an entireCarand accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.
– Broots Waymb
Dec 27 at 14:16
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
3
3
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, a
Car object wouldn't need have properties for every single component. You could break the engine components into a separate Engine object, which exists in a Car. Then you could pass just do something like TheMethod(yourCar.Engine) rather than passing an entire Car and accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.– Broots Waymb
Dec 27 at 14:16
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, a
Car object wouldn't need have properties for every single component. You could break the engine components into a separate Engine object, which exists in a Car. Then you could pass just do something like TheMethod(yourCar.Engine) rather than passing an entire Car and accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.– Broots Waymb
Dec 27 at 14:16
add a comment |
1 Answer
1
active
oldest
votes
I assume that your BO is a class (and not a struct). Then what the method gets is a single reference to this BO, not a copy of all the properties
void Method(BO bo)
{
// Here bo is a reference to the passed business object.
// No properties have been copied.
}
Therefore, it is not a problem to call the method with a large Business Objects having many properties.
Another aspect is conceptual. The Interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use (and a property is a pair of getter and setter methods). Therefore, you cloud formulate different aspects of the BO through different interfaces. Let's assume that this method wants to print the address. Only a few properties belong to the address.
public class CustomerBO : IAddress
{
#region IAddress members
public string Street { get; set; }
public string City { get; set; }
public string Zip { get; set; }
#endregion
// ... lots of other properties here
}
The method
void PrintAddress(IAddress address)
{
// This method does not need to know other proeprties.
}
The advantage is that other objects could implement IAddress like a supplier. This enhances the reusability of the method.
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of thePrintAddressmethod it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.
– Olivier Jacot-Descombes
Dec 27 at 14:37
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I assume that your BO is a class (and not a struct). Then what the method gets is a single reference to this BO, not a copy of all the properties
void Method(BO bo)
{
// Here bo is a reference to the passed business object.
// No properties have been copied.
}
Therefore, it is not a problem to call the method with a large Business Objects having many properties.
Another aspect is conceptual. The Interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use (and a property is a pair of getter and setter methods). Therefore, you cloud formulate different aspects of the BO through different interfaces. Let's assume that this method wants to print the address. Only a few properties belong to the address.
public class CustomerBO : IAddress
{
#region IAddress members
public string Street { get; set; }
public string City { get; set; }
public string Zip { get; set; }
#endregion
// ... lots of other properties here
}
The method
void PrintAddress(IAddress address)
{
// This method does not need to know other proeprties.
}
The advantage is that other objects could implement IAddress like a supplier. This enhances the reusability of the method.
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of thePrintAddressmethod it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.
– Olivier Jacot-Descombes
Dec 27 at 14:37
add a comment |
I assume that your BO is a class (and not a struct). Then what the method gets is a single reference to this BO, not a copy of all the properties
void Method(BO bo)
{
// Here bo is a reference to the passed business object.
// No properties have been copied.
}
Therefore, it is not a problem to call the method with a large Business Objects having many properties.
Another aspect is conceptual. The Interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use (and a property is a pair of getter and setter methods). Therefore, you cloud formulate different aspects of the BO through different interfaces. Let's assume that this method wants to print the address. Only a few properties belong to the address.
public class CustomerBO : IAddress
{
#region IAddress members
public string Street { get; set; }
public string City { get; set; }
public string Zip { get; set; }
#endregion
// ... lots of other properties here
}
The method
void PrintAddress(IAddress address)
{
// This method does not need to know other proeprties.
}
The advantage is that other objects could implement IAddress like a supplier. This enhances the reusability of the method.
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of thePrintAddressmethod it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.
– Olivier Jacot-Descombes
Dec 27 at 14:37
add a comment |
I assume that your BO is a class (and not a struct). Then what the method gets is a single reference to this BO, not a copy of all the properties
void Method(BO bo)
{
// Here bo is a reference to the passed business object.
// No properties have been copied.
}
Therefore, it is not a problem to call the method with a large Business Objects having many properties.
Another aspect is conceptual. The Interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use (and a property is a pair of getter and setter methods). Therefore, you cloud formulate different aspects of the BO through different interfaces. Let's assume that this method wants to print the address. Only a few properties belong to the address.
public class CustomerBO : IAddress
{
#region IAddress members
public string Street { get; set; }
public string City { get; set; }
public string Zip { get; set; }
#endregion
// ... lots of other properties here
}
The method
void PrintAddress(IAddress address)
{
// This method does not need to know other proeprties.
}
The advantage is that other objects could implement IAddress like a supplier. This enhances the reusability of the method.
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
I assume that your BO is a class (and not a struct). Then what the method gets is a single reference to this BO, not a copy of all the properties
void Method(BO bo)
{
// Here bo is a reference to the passed business object.
// No properties have been copied.
}
Therefore, it is not a problem to call the method with a large Business Objects having many properties.
Another aspect is conceptual. The Interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use (and a property is a pair of getter and setter methods). Therefore, you cloud formulate different aspects of the BO through different interfaces. Let's assume that this method wants to print the address. Only a few properties belong to the address.
public class CustomerBO : IAddress
{
#region IAddress members
public string Street { get; set; }
public string City { get; set; }
public string Zip { get; set; }
#endregion
// ... lots of other properties here
}
The method
void PrintAddress(IAddress address)
{
// This method does not need to know other proeprties.
}
The advantage is that other objects could implement IAddress like a supplier. This enhances the reusability of the method.
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
edited Dec 27 at 14:29
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
answered Dec 27 at 14:06
Olivier Jacot-Descombes
65.4k885136
65.4k885136
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of thePrintAddressmethod it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.
– Olivier Jacot-Descombes
Dec 27 at 14:37
add a comment |
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of thePrintAddressmethod it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.
– Olivier Jacot-Descombes
Dec 27 at 14:37
2
2
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Or have CustomerBO have an IAddress Adress property
– Magnus
Dec 27 at 14:28
Yes. From the perspective of the
PrintAddress method it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.– Olivier Jacot-Descombes
Dec 27 at 14:37
Yes. From the perspective of the
PrintAddress method it makes no difference and enhances its reusability even more. Whether you do this also depends on whether you have distinct view models, BOs and DTO's or not and whether you want to store the BO in a single table, etc. It's good to have both options to choose from.– Olivier Jacot-Descombes
Dec 27 at 14:37
add a comment |
ultimately, it's entirely up to you. Personally I'd consider doing so bad design, as you now have 2 object types resembling effectively the same thing.
– user2366842
Dec 27 at 14:09
3
Aside from the actual question, can you break your object down into smaller pieces? 50 properties is quite a lot.. For example, a
Carobject wouldn't need have properties for every single component. You could break the engine components into a separateEngineobject, which exists in aCar. Then you could pass just do something likeTheMethod(yourCar.Engine)rather than passing an entireCarand accessing only Engine-like properties. It's mostly a maintainability/readability thing IMO.– Broots Waymb
Dec 27 at 14:16