Thinking about the correct division of layers in systems using AtomsFramework have one question: the correct localization of type, size and required atributte was the business layer. Then, the best place for size, type and required attribute was in AtomsFramework.xml. Of course, in data base this information was too (redundant for security).
[]s
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In terms of how the framework handles types, when an application is designed the business classes have to have attributes of a specific type (ie integer, string, etc) otherwise the compiler complains.
Likewise, the database has to have columns of specific types. By putting a type in the attribute mappings in the XML we are merely duplicating data, for no benefit. If you want the type of the attribute in the business object, use the GetType() call. If you want the type of the column in the underlying database use the getStorageTypeByName() call.
The required flag can be "simulated" by coding the isValid function in the business object to returrn false when the required fields are not populated. Required attributes should be determined by the business classes, and not the Framework XML, and even though you can put a "not null" on your database columns, this is not really the best place to trap required attributes.
Finally, size restrictions for attributes can be determined in two ways, either using the getStorageSizeByName() call, or by simply coding the Set property of the attribute to return an error when the value is greater than the allowed length (for example with integers).
I don't know if that answers the question, and I'd appreciate any feedback or specific examples of what you are trying to achieve.
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand your comments.
But, I think that size, type and required flag must be main in business layer, because its properties are business rules. The functions getStorageSizeByName, getStorageTypeByName are useful, but, I think that the correct localization for recover sizes, types, etc, is the XML file (business layer).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you need to try and give me an example of what you are trying to do. The business layer (as traditionally defined) consists of the business object class definitions that you code in .NET (eg a customer object). This, by default, will store type information and the business rules.
The XML file is merely a mapping of the business layer classes onto a relational database store. It should contain no business knowledge as such, since the mappings can change depending on the database being used and the structure of the underlying tables.
All encapsulation of business rules and class properties should be within the business classes themselves. So if the customer object only allows a 4 digit customer number then the CCustomer class should be written in such a way as to enforce this integrity. If you wish to autogenerate field size restrictions in forms, you can add a property to the CCustomer class that returns the maximum length of the customer number, and this can be used to bind to the MaxLength property of a text box, for example.
Once again, if you can give me a better idea of what you are trying to achieve maybe I can understand what you are after more clearly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My question is where the informations about type, size and required flag should be gotten: in the data layer (how is now) or in business layer (in xml file, for example).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Information about type, size and required flags should be retrieved from the business objects themselves (ie the classes).
Information about a property type can be obtained using GetType.
Information about a properties size can be coded into the class definition by providing a read-only size property for each data property. Also, the set portion of the property can be coded to check sizes of values are within bounds.
Information about the required flag can also be coded into the class. You can set the IsValid function to return false when the business class required properties are not set and true when they are. Also, in your windows forms you could bind the OK buttons enabled property to the classes IsValid property and you will find that the OK button turns on/off based on wether the required fields are populated.
I hope this helps.
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem isnt use the size, type and required in classes. The problem is where its informations are gotten (its source).
I think that the best place is in xml file because it is more business layer than data base. But, it is more conceptual than practice.
[]s
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dears,
Thinking about the correct division of layers in systems using AtomsFramework have one question: the correct localization of type, size and required atributte was the business layer. Then, the best place for size, type and required attribute was in AtomsFramework.xml. Of course, in data base this information was too (redundant for security).
[]s
I don't quite follow what you are saying here.
In terms of how the framework handles types, when an application is designed the business classes have to have attributes of a specific type (ie integer, string, etc) otherwise the compiler complains.
Likewise, the database has to have columns of specific types. By putting a type in the attribute mappings in the XML we are merely duplicating data, for no benefit. If you want the type of the attribute in the business object, use the GetType() call. If you want the type of the column in the underlying database use the getStorageTypeByName() call.
The required flag can be "simulated" by coding the isValid function in the business object to returrn false when the required fields are not populated. Required attributes should be determined by the business classes, and not the Framework XML, and even though you can put a "not null" on your database columns, this is not really the best place to trap required attributes.
Finally, size restrictions for attributes can be determined in two ways, either using the getStorageSizeByName() call, or by simply coding the Set property of the attribute to return an error when the value is greater than the allowed length (for example with integers).
I don't know if that answers the question, and I'd appreciate any feedback or specific examples of what you are trying to achieve.
Richard.
I understand your comments.
But, I think that size, type and required flag must be main in business layer, because its properties are business rules. The functions getStorageSizeByName, getStorageTypeByName are useful, but, I think that the correct localization for recover sizes, types, etc, is the XML file (business layer).
Hi Marcos,
I think you need to try and give me an example of what you are trying to do. The business layer (as traditionally defined) consists of the business object class definitions that you code in .NET (eg a customer object). This, by default, will store type information and the business rules.
The XML file is merely a mapping of the business layer classes onto a relational database store. It should contain no business knowledge as such, since the mappings can change depending on the database being used and the structure of the underlying tables.
All encapsulation of business rules and class properties should be within the business classes themselves. So if the customer object only allows a 4 digit customer number then the CCustomer class should be written in such a way as to enforce this integrity. If you wish to autogenerate field size restrictions in forms, you can add a property to the CCustomer class that returns the maximum length of the customer number, and this can be used to bind to the MaxLength property of a text box, for example.
Once again, if you can give me a better idea of what you are trying to achieve maybe I can understand what you are after more clearly.
Richard,
My question is where the informations about type, size and required flag should be gotten: in the data layer (how is now) or in business layer (in xml file, for example).
Information about type, size and required flags should be retrieved from the business objects themselves (ie the classes).
Information about a property type can be obtained using GetType.
Information about a properties size can be coded into the class definition by providing a read-only size property for each data property. Also, the set portion of the property can be coded to check sizes of values are within bounds.
Information about the required flag can also be coded into the class. You can set the IsValid function to return false when the business class required properties are not set and true when they are. Also, in your windows forms you could bind the OK buttons enabled property to the classes IsValid property and you will find that the OK button turns on/off based on wether the required fields are populated.
I hope this helps.
Richard.
Dear,
The problem isnt use the size, type and required in classes. The problem is where its informations are gotten (its source).
I think that the best place is in xml file because it is more business layer than data base. But, it is more conceptual than practice.
[]s