Hello,
"KMZ_state" <KM******@discussions.microsoft.com> wrote in message
news:3F**********************************@microsof t.com...
We have a debate here. We are receiving a CSV file specified by the user
and
need to validate the contents, writing the "good" records to the database
and
displaying the "bad" records to the user. One developer wants to loop
through the CSV file right on the web layer (ASPX) and then only pass the
"good" records onto the DAL. The other developer wants to pass the whole
file as an OBJECT to the business logic layer and then loop through there,
passing onto the DAL the "good" records and returning the "bad" records
back
to the web layer to be presented to the user.
Is there a "best practice" here? The first developer is looking at the
file
as just another user input to be validated, while the other developer is
looking at the file as an object, to be passed through to the BLL. Any
insights or recommendations?? Thanks!
What makes sense for your design depends on your requirements. If the CSV
file is small, then loading the entire thing into memory before validating
any of it is just fine. On the other hand, if it can become quite large,
you are better off treating each line as a seperate transaction, just so you
don't have to spend a lot of memory on keeping it all loaded at once.
In general, I'm a fan of Service Oriented Architecture. That means that
when a file is received that contains 1000 records, you would respond with a
file that contains the 5 bad records, and you would accept the rest for
processing. Now, that 'work' can happen at any service interface, and the
'file' that contains the bad records could go to your web site for display,
instead of back to the user... but keep in mind that if you were talking a
SOA system, I'd say that the display mechanism must be completely seperate
from the transaction validation mechanism.
Therefore, if the user uploads data, I'd parse it first. One transaction at
a time: create an object, load the data into the object, validate the
object. If it fails, send it to a service for handling 'bad' messages. If
it passes, send it to the service that persists. Then read the next
transaction.
The service for handing bad messages handles the display/edit/resubmission
process.
I hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
