Nov
12
posted at: 12:46 PM
Below are my noites and reaction on topics I explored from the first half of DevConnections that I felt were worth reflecting on. There were some sessions that I have to admit I didn't get much out of, so I've chosen not to react to those.
Entity Framework
Entity Framework allows you to compile a queryable collection of relational object entities that interfaces very will with LINQ and WCF. I think it is a great solution for projects that need to aggregate multiple data types together or projects where the data source is expected to change. Other than that, we may be overcomplicating a simple problem by adopting it for basic projects that only need get their data from SQL Server. One day I'm sure I will use it, but not in the forseeable near future.
ASP.NET MVC
MVC is not a required learn. Webforms are not going away, we are not going to lose our jobs if we don't learn MVC. Also, Scottgu does not like to be called "The Goo." He prefers to be called "sir." Also, if you ever get a chance to attend a Hanselman session.. yeah he is fricking hilarious. Awesome presentations!
My happiest moment in the MVC session was to see that their integrated URL Rewriting does not require a file extension! My second happiest moment was that he named his project, "Poo." He ran the project and got the error, "The view 'Poo' or its master could not be found."
MVC is actually incredibly simple, and feels a lot like the classic round-trip of pre-.NET days. The difference is modularity in an environment that locks you into a very structured n-Layer architecture. This is good if you embrace it, as it forces your business logic to be completely isolated. You can mix and match Webforms with MVC, so you can use either where it's appropriate, because with MVC you lose all of the native ASP.NET eventing.
MVC looks great for applications, but not so great for marketing websites. The integrated URL rewriting is not so SEO-friendly.
SQL Server Reporting Services
In a nutshell, SQL Server Reporting Services has the potential to replace the reporting work I do on a regular basis by providing a web delivery mechanism with numerous exportable options. The view can take parameters in the QueryString to help format what report the user wants to run and what data they can get back, and allow me to customize the UI of the report by using a WYSIWYG tool. The session I attended on the topic focused more on the programattic elements of reporting, particularly on the web services available for SSRS which I probably wouldn't use, but this solution is worth exploring further so that our report developers (mainly me) won't be in a silo, and that we have a standardized platform for report delivery when we have future reporting requirements across multiple applications.
If you can't already tell, I was pretty lost during this session, mostly because of my lack of any experience with SQL Reporting Services, which served as a prerequisite for attending the session. Regardless, I got what I was looking for out of it.
LINQ and N-Layer
I was pleased to see that Dan Wahlin started his talk on this topic by defining the difference between N-Tier and N-Layer, and how regular implementation of N-Layer architecture promotes code re-use and cross-collaboration between developers. I think that my team does this well, but the layers are inconsistent across applications due to numerous developers creating and modifying them and how the framework has evolved over time. I think this is a challenge that many organizations face, though.
It seems that a common theme throughout many of the sessions is that people are really pushing formalized unit testing. Another common theme is that almost nobody is doing anything with Silverlight yet.
I really like how Lambda expressions mirror more of an object-oriented approach which would be a better fit for my coding style than standard LINQ expressions, though I still feel like a purist in keeping more query logic in the data layer using stored procedures. If nothing else, utilizing LINQ to SQL is going to save me time writing mundane data access methods to pull from stored procedures, as it will automatically map return fields into generic collections of entities. The problem that might occur is that I might wind up with a property named "person_name" instead of "PersonName." I'll have to play with it and see what happens.
One challenge with this approach is that the code generator for the LINQ to SQL context embeds the databse connection string, which would mean you would have to change the connection string in multiple places when publishing to different environments. Dan's solution to this is to create a class dedicated to retrieving the connection string from the web.config. Dan actually had a slide dedicated to this issue and it's very easy to implement after you've generated your Data Context by setting context.Connection.ConnectionString to the ouptut of the dedicated method on the dedicated connection class.