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.

I read a blog post recently where someone wrote a simple test app that used 3 different methods to set a property of a class 1000 times and tracked the overall performance. The results were a bit eye-popping:

• Reflection: 20 seconds
• Dynamics: .6 second
• Normal Property Setter: .01 second

Dynamics appear to offer a significant performance boost over reflection. Of course, it could/will vary with regard to how dynamic is used. I work with an application that uses a great deal of reflection and I’m interested to see how I might be able to switch it over to using dynamic more and see if I can boost performance.

So I’ve been using Bing exclusively for a few weeks now and I must say that I am impressed. Here’s my run down:

• The search results are as good, if not better than Google.
• Bing has less intrusive advertising cluttering the screens on most searches than Google does.
• Bing seems to be smarter about the user’s query. It correctly interprets the intent of the search and provides quick information and related searches on many topics.
• The kicker for me though is the infinite scroll that Bing does on image searches. I love me some infinite scroll! Clicking through pages of results is not fun at all. I wish they would do that on regular searches too.
• I’m not really in to frilly lace type features, but the intelligent background images provided on Bing are cool. As you hover over certain areas of the image, information about the image/place/etc… is provided.

I’m a fan, and I think Bing has won me over for my default search engine. The technical queries that I have thrown at it have all gotten me where I need to go. Honestly, I think they have out done Google here. Only time will tell if they can make a dent in Google’s stranglehold of the market though.

I just read a postfrom Scott Hanselman that mentioned a tool that I hadn’t recalled hearing about before called the Fusion Log Viewer, also called the Assembly Binding Log Viewer. It appears to be available as part of the framework install. I found two instances of the executable on my development machine, both under C:\Program Files\Microsoft SDKs\Windows.

What is so special about Fusion Log Viewer? Well, not that much, but it could be helpful if you are having an issue with a wrong version of an assembly being loaded at runtime or an assembly not being found to load at runtime. Other tools such as .NET Reflector and Process Explorer can help you debug concrete references and what has already been loaded explicitly, but if you are doing dynamic assembly loading this tool may be useful.

The past couple of days I have been testing Beta 1 of Visual Studio 2010 Team System and have quickly realized that it is highly unstable and contains many frustrating bugs. If you are thinking about starting to use Beta 1, I would highly suggest holding off until Beta 2. Visual Studio 2010 appears to be in worse shape than the early releases of Vista; the complete opposite of my experience with the Windows 7 Beta release I might add.

So what have I seen that has caused me to come to the above conclusion:

1. Random crashes where Visual Studio disappears without a trace, no error messages. I have seen this several times converting solutions and projects from 2008 format to 2010, as well as, in the middle of compiling solutions.

2. C++ projects appear to be defaulted and fixed at “.NET Framework 4.0” which then causes it to be incompatible with 3.5 projects.

3. I have seen odd errors with project references not being picked up. I still have not gotten to the bottom of this one, although some of it is related to #2.

4. The Errors window does not always clear out between builds, leaving one thinking there are still errors after a successful compile.

5. Changes to Target Framework in Project Properties do not always save.

6. Project properties will not display at all for some normal C# assemblies.

I have every confidence that the DEV team at Microsoft will address these issues and many of the others, but for now, the Beta release of Visual Studio 2010 just is not ready for any real use other than playing around. It’s a Beta so that is to be expected. I just got my hopes up after how well Microsoft did with their Windows 7 Beta.

Recently came across this site which has a rather large cache of reported interview questions that various companies ask. In looking at the software list it seems most of them are from Google and Microsoft. None the less, could provide a good warm-up prior to venturing into an interview session.

In addition to my previous post, I found another free stock photo site that looks promising called Stock Xchng.

Ok, let me start this out by saying I knew better than to purchase a refurbished product from Stootsi, but I did it anyway. A few days ago a deal came across the wire from Stootsi that had the Microsoft Natural Ergonomic Keyboard 4000 for just $9.99. For those that pay attention to keyboards, this is not only one of the best keyboards out there, it is also a very good deal for one. I saw that it was refurbished, and, as a matter of rule, I never buy refurbished products. If it broke once it is probably going to break again. However, for merely ten bucks, it was just too good to pass up. I did some searching on Stootsi and although they weren’t rated one of the best retailers out there, they weren’t too bad.

So, I bought it and about a week later it arrived. Pretty good shipping time for a fire-sale joint like Stootsi. Got the keyboard out, and it was obviously used, but still in good shape astheticly. So I plugged it in and first thing I did was download the software for it so that I could test all of the quick-buttons on the keyboard. To my delight, they all worked fine. Ne-t test, do all of the letters and numbers work. This one passed e-cept for the letter missing from the words in this and the previous sentence (still typing on the ‘new’ keyboard). So, obviously, the product wasn’t actually refurbished, it was simply repackaged. There is the first ding for Stootsi.

Well, the worst part of it is Stootsi’s return policy, which I neglected to read prior to purchasing from them:

Every item we sell, whether it is on our homepage or in the store, has a "warranty" graphic beside the item explicitly stating the type of warranty, if any, that is offered. Based on the condition of the item (new, refurbished, overstock/liquidation, returns), there may or may not be a manufacturer's warranty. Any problems with a product that is under manufacturer warranty will be handled directly with the manufacturer. Stootsi will however assist you in receiving warranty support with the manufacturer if neccessary. Due to the ridiculously low prices that we offer, no returns are accepted for buyer's remorse. Ideally, you will just sell your item that you don't like on ebay, and maybe even make some money in the process. If no warranty on a product is given, and it arrives defective or Dead On Arrival (DOA) you must notify us within 3 days via email at rma@stootsi.com. After 3 days all sales are final. Return shipping will be at your own expense. Stootsi does not offer replacements in any situation and you will receive a refund of your sale price only.

So, the shipping cost is on me both ways which in this case adds up to more than the product cost. My net gain by returning the defunct item would be a measly $3 and I would end up with no keyboard. Stootsi is running a scam; repackaging broken/defective products.

DialMyCalls lets everyone tap into the power of sending voice messages out to entire phone lists in seconds. No messing around with expensive equipment or calling servers - now you can send your own voice messages from 2 to 20,000 phone numbers all within a few minutes.

Free Service:

• You may send 1 call per day to a maximum of 25 people.
• Messages must be 30 seconds or less in length.
• Calls branded with a "Powered by DialMyCalls message"