CSLA .NET

Hello!

I am building my first CSLA project and I have run into a class design issue that has me stuck.

The application I am building takes in student loan data from various business partners via Excel files. Each row in a spreadsheet represents a single loan, however the columns provided vary in number and name depending on the business partner who sent it to us. Currently my application creates a table in the database with a set of columns that match the columns in the incoming spreadsheet and then dumps the data into this table.

My problem is that I want to show this data to the user in a winform datagrid but I want to use a CSLA object instead of a datatable and bind directly to the grid via a binding source. However, because the number and names of the columns in the db table are not fixed, I cannot figure out how to design a CSLA class that I can populate with the loan data and display in a grid.

I have read all sections of the book that seem relevant to this but all examples seem to have a fixed # properties. Since I am new to CSLA, I am sure I am just missing an obvious solution... Has anyone solved this type of issue before?

Thanks in advance!

I did not solve it from a CSLA point of view. I took a different tack.

I import Excel files using ADO.Net into a Datatable. Then I bind the datatable to the grid for presentation to the user.

If the goal is to then bring in the data to a single DB table and have it validated by a CSLA BO then you also need to be able to map a supplier file to the CSLA BO properties.

e.g. PartNum maps to Partno property.

The key is that every spreadsheet is a subset of all possible property names.

Then you can loop over the datatable and import 1 row at a time, validate the data (maybe partial amounts of data are OK as long as the key fields are filled in) and then save it to the DB. If thee is an exception during validation or save, write to a log and continue processing the remaining rows.

Joe

 

I may have to go the non-CSLA approach as well then.

The first step as I mentioned is to load the data from the spreadsheet into the db table and then present it to the user in a grid control so they can make decisions on which source columns map to which destination columns. If a destination column does not exist, the user then creates it.

The dynamic nature of the the incoming source file columns as well as the list of possible destination columns seems to make this application incompatible with CSLA since I cannot really create a class that represents the source or destination columns (properties).

Thanks for your quick response Joe,
-Jason

That does sound like an odd problem!  It would make sense to think that if these are all loans then they will all share some common properties and behavior. 

Just a suggesstion but if I was faced with something like this I would create some form of a mapper class that would take the data from the excel spreadsheet columns and map that data into the object and then into the database.  If all the data is indeed related to a loan some common properties should be extracted out.

Everything common to all the loans from all your business partners would be the basis for a base loan class.  Maybe a derivative of the loan would be required for each partner.

I have had cases that were somewhat similar and I had a table to store the basic data and would create extension tables for the subclasses and put the extended data in there via a junction table that was linked on the base tables primary key.

So I would have some tables like baseObject and then a table baseObjectExtentions.  I could pull an exteded object from the database using a view, this just makes updates a bit tricky.

This doesn't sound like a problem with CSLA but more a problem with the data and object structure.  Good luck with your project.

---

Building tomorrow's legacy applications today!

Justin,

Thanks for the reply, I agree the problem is with data and object structure, not CSLA. The dynamic nature of the data I am dealing with seems to be incompatible with any real object modeling. For example there may be hundreds of partners and each file can have hundreds of columns of data describing the loans. Each column can be spelled however the partner decides(Social Security #, SS#, Soc#, SS...) The permutations are huge and the human’s job is to decide on the correct mapping for each column. In addition there are multiple domains possible... For example, the user can define a new domain for car loans, personal loans etc. each having their own set of destination columns that the user defines.

This is actually a reimplementation of an existing application that does all of this stuff already but in a ‘by any means necessary’ implementation which is an obvious nightmare to maintain. My goal is to use CSLA bring some solid architecture to the app and hence add a few years to my life expectancy (you guys are saving lives!).

What I think I may do is keep the DataTable at the core of the app to handle the dynamic nature of the data I am working with and then use CSLA for all supporting meta data and data entry forms. CSLA will work wonders in these parts of the app.

Thanks a bunch for your help!

This sounds like a problem waiting to get worse. Why not specify to your providers of the data a data contract, of what data you want?? Then I agree with what justin said.

Unfortunately that is not a feat a lowly programmer like myself could pull off. It would require an industry wide standard that currently does not exist or is being ignored. Like I mentioned, there are hundreds of potential partners (basically anybody with a pool of loans they are looking to sell) and my company is effectively in an environment where they are bidding against many competitors for those assets.

Your next question might be "why hasn't anybody established standards like in other industries?" which is a good question. My best answer would be that it is an "asset holders market" and with the ever changing nature of the asset holders (from 20 person hedge funds to 100K staffed banks) nobody is going to say "we will only look at your assets if you spell your field names correctly" that may risk missing out on a billon dollar transaction... In addition the products are very diverse. It could be student loans, auto loans today but then energy assets, comodities... tomorrow. Establishing standards would be a huge undertaking and may never happen.

Also, like I mentioned, I am re-implementing an existing application that already does this job and does it quite well. So as far as the business is concerned, the fact that i cannot use coherent architecture like CSLA is not an issue.

Thanks!
-Jason