Grouping Large Amounts of Properties.

DeHaynes posted on Monday, June 01, 2009

I have a tough situation. I am trying to implement CSLA objects on a system that I inherited. The primary entity type is a Client. The data for a client exists in 3 tables that reside in 3 different databases. Two of the databases belong to 2 canned applications and I therefore cannot modify them. The third database hold all our custom fields. The client entity consists of over 100+ fields. My problem is that there are a lot of fields to mix together. It would be nice to be able to organize the fields into sections like demographics, configuration, company contacts, etc. The preferred way would be to be able to do something like "Client.ContactInfo.AddressLine1" for the names, but the only way I know to do this is to create subclasses. Does anyone know of a way to accomlish this without subclasses or a better way to deal with so many properties? Remember, I cannot restructure the tables.

RockfordLhotka replied on Monday, June 01, 2009

Your objects should be designed around behavior and user scenarios, not around the shape of the data.

Do you have a single screen with 100+ data entry fields on it? If so, then you should probably have an object with 100+ properties.

Otherwise you almost certainly have a major mis-match between your object shapes and your business requirements.

Remember that the data access layer (either the code in the DataPortal_XYZ methods, or in your DAL) is responsible for mapping data from the databases into/out of your objects - thus decoupling the shape of the objects from the shape of the database, and allowing your objects to be shaped according to the needs of your application's usage scenarios.

DeHaynes replied on Monday, June 01, 2009

The application I am writing is to sync data between a hyrbrid (three database) system and Ms CRM. My use case is the ability to sync Adds, Deletes and Edits between both systems. I have already created the entities and interface in CRM. I have also written code for both systems to write Adds, Edits and Deletes to an XML so a syncing application can push the changes between the systems. My current step is to create the Business Objects and then create two factories, one for CRM and one for the Hybrid-System.

Your comment about "Do you have a single screen with 100+ data entry fields on it? If so, then you should probably have an object with 100+ properties." made me think deeper on this and fact is, the three different tables that make up Client business object all key off the same number as their primary key. This number is copied to each table, in each database. Again, I didn't design this, I inherited it. In reality there are over 300+ fields to this entity but there is enough duplication and unused features that it boils it down to 100-ish fields. So my question isn't whether I must have these properties. My question is "Does anyone know a way of organizing properties in Ms Intellisense?"




Thanks.

RockfordLhotka replied on Monday, June 01, 2009

My next question then, and I realize you inherited this, is why are you
using CSLA?

This sounds like a class data transfer/mapping scenario, where tools like
those in SQL Server, BizTalk or third parties like Data Junction are a
classic match?

Rocky

DeHaynes replied on Monday, June 01, 2009

To be honest, I have been trying to get back into CSLA for 2+ years now. So I was sort of using this as an excuse.

Considering the lack of normalization in the databases, I figured I would have to do a ton of configuration to get things like that to work. I tried to use some class generators for the entities before and the lack of normalization completely hosed me.

I also didn't realize those application could handle web services. Which is the preferred method of interacting with CRM.