Array and Array Operations in Windows PowerShell

Object Relational Mapping

With .NET 3.0/3.5, MS has finally released not one but two ORM toolkits. I say finally because MS previously promised an ORM toolkit to developers in the form of a project called ObjectSpaces. ObjectSpaces was never released and its demise is clouded in a series of potentially bad integrations with WinFS, Project Green, or the MS Business Framework, all of which were eventually cancelled.
The spark that reignited MS ambitions to produce an ORM was the Language  Integrated Query (LINQ) project. LINQ’s goal as part of C# 3.0 and Visual Basic  9.0 was to provide a set based metaphor for dealing with heterogeneous data types including object collections, XML, and last but not least, relational data.
For the relational component of LINQ, the language team came up with a project called LINQ to SQL and shipped it as part of .NET Framework 3.5.
During the same time period, the Data Programmability Group in the SQL Server team had been working on a new layer to sit over top of SQL Server’s logical data model. This new “Entity Data Model” (EDM) would allow developers to interact with their relational database using a more abstract conceptual model based on the ideas of Dr. Peter Chen. For this team, the promise of Language Integrated
Query was what really brought the notion of the EDM to life, and so began the
“Entity Framework” project. The Entity Framework did not ship until several months after LINQ to SQL as part of the .NET 3.5 Service Pack 1 release.
On the outside, LINQ to SQL and the Entity Framework ORMs appear very similar. Both tools use a graphical design tool and wizard to map a relational database into an object model. They can both use LINQ queries to project relational data into objects using composable queries. Both provide change tracking so that changes made to the objects can be persisted back to the database with a single method call.
Given these similarities, Microsoft has spent some considerable energy in explaining when to use each of these technologies. While these two ORMs have strong similarities in programming models, their internal architectures are quite different. These key differences are:
LINQ to SQL has been locked directly to SQL Server, whereas the Entity
Framework includes a provider model that allows it to work with any relational engine. As mid 2009 the list of available providers in the ecosystem included SQL Server, Oracle, Sybase, DB2, Informix, MySQL, PostgresSQL,
SQLite, OpenLink Virtuoso, and Firebird.
LINQ to SQL does not provide a mechanism for streaming records one at a time. Using Entity SQL, the Entity Framework can provide Data Reader style access to results using the same mapping layer used for object queries.
LINQ to SQL provides an out of the box experience for lazy loading. Lazy loading allows the engine to automatically (by default) go out and retrieve new data as it is needed based on code that access different elements of the object graph. In the Entity Framework, you have to be explicit when you make trips to the database. Both ORMs allow you to load deep object graphs eagerly as well.
Perhaps the largest difference between Entity Framework and LINQ to
SQL is the conceptual modeling layer that EF provides. EF provides a much richer mapping layer than LINQ to SQL, allowing you to join tables together, provide elaborate class hierarchies with abstract and concrete types, and retain many-to-many relationships in your model. Future plans will see the conceptual model being used in other MS products such as SQL Server
Reporting Services and SQL Server Analysis Services.
Finally, expect to see significant investment in the Entity Framework ORM from Microsoft. Both ORMs are now managed by the same product team at MS and they have stated that while LINQ to SQL will continue to be supported and maintained, future innovation will be focused on the Entity
Framework.

DataSets, DataTables, Data & Table Adapters

With DataReaders you need to be careful about how long you keep your connection open while iterating. Sometimes it is better to pull back your entire result set into memory, release your connection to the database, and then process the result set afterwards. This is where DataSets can be helpful. If you have a batch processing scenario that requires the entire result set in memory or you need to provide end user editing in a grid control, then DataSets are a good place to hold that data.
One of the primary benefits of a DataSet is that it not only caches the data in an efficient memory structure, but it can provide change tracking (what records were added? Deleted? Changed? What were the original values of each column, etc). DataSets work collaboratively with a SqlDataAdapter object, which is simply a composite of 4 SqlCommands (InsertCommand, SelectCommand,
UpdateCommand, and DeleteCommand) mapping to the appropriate CRUD behavior (create, read, update, and delete).
DataSets can contain multiple result sets, each mapped into its own DataTable.
Tables can be related to each other with Relations which mimic foreign keys.
DataSets take care of master-detail linkages and keep everything “hooked up” when inserting records into parent and child tables with identity columns. Each table will require its own SqlDataAdapter. If you are doing a mix of insert,updates, and deletes and your database has referential constraints, you’ll need to orchestrate the changes, making sure parent records are inserted before children and that deletions happen in the reverse order.
DataSets/DataTables come in two flavors: typed and untyped. Untyped DataSets simply infer the table and column definitions after executing the SqlDataAdapter.
Fill method. Accessing the columns must be done similarly to DataReaders using column names in quotes or by positional reference. Typed Datasets on the other hand use wizards and a design surface to generate a strongly typed object. The typed dataset is defined by an XSD document. The XSD is then turned into a strongly typed/named class that essentially sits on top of an untyped dataset. A table mappings collection on the SqlDataAdapter class allows you to use different names for your strongly typed object than that of your database table and column names.
Many people in the .NET 1.0-2.0 era used typed datasets as business entities and wrapped some additional business logic around them. Although you could map column names, you were typically tied tightly to your table design in the database. DataSets can also be converted to and from XML, including a diffgram format that retains pending change information. In many circles, DataSets have and continue to be serialized between distributed layers of an application.
This makes for a pretty productive development environment, but has drawn architectural criticisms compared to properly modeled services with messages and contracts.
In .NET 1.0, DataAdapters and DataSets were different objects that really didn’t know about each other until you executed the DataAdapter Fill or Update method and passed the DataSet/DataTable to the respective method. It was possible for the table mappings in the SqlDataAdapter to get out of sync with the strongly typed dataset. To improve this situation, Microsoft introduced
TableAdapters in .NET 2.0, which are really just DataAdapters that are strongly typed and embedded into the definition of the typed dataset.

Remaining Valuable to Employers

Billy: Developers these days, I think, one of the most value things they can do is get a feel for the parts of their job that are not really what they necessarily like to do but what adds more value and gives them more visibility within their organizations. They need to talk to users more. They need to have more empathy with their users and with the business leaders and try to see things from their point of view. I think that’s something that developers aren’t very good at, and if they improve those skills, then they make themselves valuable in ways that, for example, can’t be outsourced. You can’t outsource empathy to
India. That simply doesn’t work. I’ve been reading a lot of books about design and such, and it’s kind of affected my thinking in terms of developers needing to engage the right-side of their brain more because there’s value to be added there. So unless somebody is just a superstar coder on the pure “let’s produce technology” side, then I think that they’re probably going to make themselves more valuable and more important in their organization to work on some of those more right-brain skills that are not in the skillset of the typical developer.
Bruce: To make yourself attractive to employers right now, I think probably the biggest thing is to be practical about it. You need to be working on things that are adding value to the employer. Ultimately the things that are new, while they’re cool and while developers love them, they have the potential to add risk to what an employer does and risk is not what employers are looking for right now. So you need to be working on pragmatic skills, skills that can be easily applied to revenue-producing things, to productivity-producing things for a particular employer.
Scott: The first thing for developers to think about is really to understand that in technology there is a value chain in the same way that there is in manufacturing.
If you’re at the end of that value chain, if you’re the last piece in the wheel, you’re the easiest one to let go when demand is falling. So the first thing is to recognize that there is a value chain and to find ways to work up that value chain, whether that’s increasing your design skills, helping out in the sales cycle, learning some new tools or technologies, analyzing the market, whatever it is. But if you’re the last spoke in the value chain, you’re going to be the easiest one to replace. Two other things I’d mention: the first one is to specialize. The world of the generalist developer, I think, is coming to an end. So it’s really important to figure out in the whole technology domain where your specialty is and to be passionate about it - that’s the last point I’ll make. Don’t just pick a specialism because you think there’s a market there. Pick a specialism because you actually like it. When you’re talking to your employer about it, be passionate. Let your passion flow through.
Adam: If I was a developer, I would try to make sure that the first thing I get right is communication. You can be a great coder, but you are not rounded until you are a great communicator. A great communicator goes and talks to users.
Doesn’t just talk to users, takes notes so they can action it. Confirms it in an email in case they still got it wrong. And then goes and actions it. And it’s no good just being a great communicator and just talking and doing more talking and no action - you’ve got to have some action. And then you’ve got to be visible. So my main points would be: talk to users, find out their pain. Talk to the boss, find out his pain. Simple questions like “What’s important to you?” Try to find out what it is, repeat it back, see if you’ve got it right, go away and see what you can do.
And become visible in other ways as well. A blog is very important. Get people’s thoughts. Speak to mentors - get a mentor! And then go ahead and action some things and get a clear understanding so you can add more value.
Jonathan: I would say that the number one key to making yourself attractive to potential employers is being able to demonstrate that you have a client focus rather than a technology focus. All too often developers are focused on the newest / greatest technology, being bleeding edge in terms of the things they are trying to implement. But if you’re able to demonstrate to an employer that what you understand are the client’s needs coming first and that delivering value for those clients is going to be your number one priority, you’re going to be the most attractive prospect for any employer.