I originally found this chart here, but since it’s licensed under the Create Commons License, I have copied it to my blog for future reference. For updates and to purchase prints see the original author.

In general I have been a big fan of Samsung electronics over the years. I have a Samsung plasma at home and 2 Samsung LCD monitors that are great. My problems started with Samsung when I purchased two internal SATA II hard drives from NewEgg in November of 2008. I use the hard drives with a Thermaltake hot swap drive bay for my rolling backup system at home. Everything worked great until April of 2009 when one of those two hard drives failed.

Not a big deal; hard drives fail, that’s why I have redundancy built into my backup plan. The fact that it failed after only 6 months is a bit concerning, but occasionally you get bad drives, and that is why there are warranties. Here’s where my problem begins: this particular hard drive has financially sensitive information on it. So I don’t want to blindly ship it off somewhere for RMA and never see the drive again. I would constantly be wondering in the back of my mind whether some random guy/gal got hold of the data on the drive and used it maliciously.

So, I called Samsung support and spoke with them about the issue. To my shock, the support representative acted as though this issue had never come up before! No one has ever had concerns over the security of their data when submitting their hard drive for RMA? Are you kidding me? He forwarded me to Total Tech Solutions, Samsung’s vendor who handles hard drive RMAs. Now as if Samsung’s response wasn’t bad enough, Total Tech Solutions was even more of a joke. The person I spoke with there gave no illusions of data security what-so-ever. His response to my inquiry was that the hard drives are received, checked and then immediately shipped to Korea. No way to have the drive shipped back to me, no way to secure the data, no way to do anything but to trust random people halfway around the world. Are you kidding me?

So, I called Samsung support a second time, described the scenario to another representative. The person then referred to the support manager present at the time, but wouldn’t let me speak to them. The response was that they could not help me. I tried to suggest several alternative means by which I could RMA the drive and still have some assurance of data security (take it to a local repair shop or Samsung dealer, have the drive shipped back to me after inspection, just trust the customer that the drive has failed and send a new one). No go. So I’m out a hard drive and the Samsung warranty is useless. I asked if there was anyone there who I could appeal to and was told flat out ‘no’! Seriously, are you kidding me?

My next step was to track down, Jon Kang, the president of Samsung Semiconductor, on LinkedIn. I sent him a message, but have not heard back. I don’t really expect to hear back given the track record that Samsung has shown me above.

So there is my sad story. I’ve learned my lesson. Never buy Samsung hard drives, and I might extend that to never buy Samsung products in general, but we’ll see. Secondly, I’ve learned that I should encrypt my backups even if they are supposed to be leaving my possession.

Some company resources for future reference.

MyCorporation

LegalZoom

The Company Corporation

BizFilings

I ran across the following today and thought it was worth republishing here to record it for later use. The original article is here.

Most line of business applications will die unless they have a strong data access strategy. Enterprise apps simply cannot afford to hard-code thousands of in-line SQL calls to an aspx code behind; the maintenance and lack of reuse and testability will kill you. I realize entire books are written on data-access strategy (Fowler, Dino/Andrea), and by much smarter men than I, so I only offer this blog post as a summary and braindump. I'm sure I've inevitably missed several important aspects. I also realize that developers take their Data Access Layers (DAL) very seriously and personally, and may consider some features more or less important than others.

Must-have features - This will get you started.

1. CRUD - Give you at least the basic CRUD (Create, Read, Update, Delete) functionality
2. Sorted paging and filtering - Provide a simple way to handle sorted-paging and filtering
3. Automatically generated - For the love of all that is good, do NOT write tons of manual data-access plumbing code by hand. Either code generate it, or use a dynamic ORM (like NHibernate)
4. Serializable objects - Domain objects should be serializable so you can persist them across the wire (such as store them in a cache). Sometimes this is solved as easily as slapping on attributes to your objects.
5. Handles concurrency - Even a where-clause check that simply compares a version (or datetime) stamp.
6. Transactions - Support transactions across multiple tables, such as either using the SQL transaction keyword, or the ADO.Net transaction (or something else?)

Good-to-have features - When you start scaling up, you're really going to want these.

1. FK and unique-index lookups - Provide those extra automatically generated FK and unique-index lookups on your tables.
2. Meta-data driven - Perhaps you define your entity model in xml files, and your process generates the rest from that (tables, SP, DAL, entity C# classes, etc...)
3. Mocked / Isolation-Framework-friendly - It could provide support for a mock database, or at least create interfaces for all the appropriate classes so you program against the interface instead of concrete classes.
4. Batching - (Includes transaction management). If you don't have the ability to batch two DAL calls together, because remote calls are relatively expensive, you'll inevitably start squishing unrelated calls into single spaghetti-blobs for performance reasons.
5. Insert an entire grid at once - This could be done via batching, or perhaps SQL 2008's new table value parameter.
6. Handle database validation errors - Ability to capture database validation errors and return them to the business tier. For example, checking that a code must be unique. (See: Why put logic in SP?)
7. Caching - for performance reasons, you'll eventually want to cache certain types of data. Ideally your DAL reads some cache-object config file and abstracts this all away, so you don't litter your codeBehinds with hard-coded cache calls. [LINK: thoughts on caching]
8. Multiple types of databases - Access multiple different types of databases, such as main, historical, reporting, etc...
9. Scales out to multiple, partitioned, databases - For example, your main application data store may be partitioned by user SSN, and hence you can spread out the load across multiple databases instead of having one, giant bottleneck.
10. Integrate with a validation framework - Perhaps by applying attributes to the entity objects (like what Enterprise Library Validation Block does), you may want your generator to be able to read both database schema info and external override values from an xml file. For example, say you have an Employee object with a "FirstName" property which maps to the EmpInfo table's FirstName column, the generator could pull the varchar length and required attributes from the database column, and then possibly pull a required expression pattern from the override xml file.
11. Audit trail for changes made - The business sponsors are going to want to see change history of certain fields, especially security and financial related ones.
12. Create UI admin pages - Provide the ability to create the admin UI pages for easy maintenance of each table. Even if you don't actually deploy these, they're a great developer aid.

Wow - These are more advanced

1. Partial update of an object - say you have a reusable Employee object with 30 fields, but you only need half those fields in some specific context, it can be beneficial to have a DAL that can be "smart" and updates only the fields that you used in a given context. Perhaps you could add a csv list to the base domain object (that Employee inherits from), and every time a property in Employee is set, it adds the field to that CSV list. Then, it passes that CSV list to the data access strategy, which only updates the fields in that list.
2. Provide a data dictionary so it integrates into other processes. Building off the meta-data approach (where you can automatically generate lots of extra plumbing to assist with integration and abstraction layers), you can start doing some really fancy things:
   1. See every instance in the UI where a DB field was ultimately used
   2. Provide clients a managed abstraction layer that lets them write their own reports given the UI views - not the backend tables.
   3. Provide clients a managed abstraction layer that lets them do mass updates of their own data (this is a validation and security nightmare).
3. N-level undo - I've never personally implemented or needed this, but I hear CLSA.Net has it.
4. Return deep object graphs - Having a domain model is great, but there's the classic OOP - relational data mismatch. ORM mappers explicitly help solve this. Without some sort of ORM mapper, most application inevitably "settle" (?) for a transaction script or table module/active record approach. A deep object graph also requires lazy loading.
5. Database independence - Configure your database for easy switch from SQL Server to Oracle. You could do this at compile time by re-writing your code-generator templates. I've heard some architects insist that you should be able to do this at run time as well via a provider model, and updating some information in the config file (I've never personally done this).

Data access is a re-occurring problem, so the community has evolved a lot of different solutions. Consider some of these:

• ORM mappers
  • NHibernate - A popular ORM mapper (and check out Hudson Akridge's blog for NHibernate expertise)
• CodeSmith-related (generates code at compile time)
  • CLSA.Net - Rockford Lhotka's super enterprise framework, which has CodeSmith support.
  • .NetTiers - A set of CodeSmith templates to create the entire DAL and UI admin pages.
  • Your own custom-built thing (via CodeSmith)
• Microsoft solutions
  • Strongly-typed .Net DataSets - This is what .Net first had.
  • Linq-to-Sql - Great for RAD apps, but I'm personally not sure how well it scales. Be sure to run SQL-Profiler on its generated sql.
  • Microsoft Entity Framework - Microsoft's offering for a domain-model approach (as opposed to their out-of-the-box typed datasets).
• I've heard about, but never personally used these:
  • Castle ActiveRecord
  • (Probably several others too...)
• In-line SQL from your Aspx codebehind - ha ha, just kidding. Don't even think about it. Seriously... don't.