- During the past month, Danny Simmons let us all officially know that SP1 of VS 2008/.NET Framework 3.5 will be the delivery mechanism for the Entity Framework and the Designer, and that we should see a beta of the entire SP1 very soon as well. No release dates yet.
- Speaking of the next beta, there have been some improvements in the designer to support iterative development. Noam Ben-Ami talks about that here.
- There is also a new ASP.NET EntityDataSource control coming in the next beta. Danny demo'd that at DevConnections, and Julie blogged about it here.
- In April, Microsoft released the .NET 3.5 Enhancements Training Kit. This includes some preliminary labs on ASP.NET MVC, ASP.NET Dynamic Data, ASP.NET AJAX History, ASP.NET Silverlight controls, ADO.NET Data Services and last but certainly not least, the ADO.NET Entity Framework. Stay tuned for updates
- Julie Lerman has created a spiffy pseudo-debug visualizer for Entity State. It's implemented as an extension method and not a true debug visualizer, but useful just the same.
- Check out Ruurd Boeke's excellent post on Disconnected N-Tier objects using the Entity Framework. His sample solution is checked in to the EFContrib Project and he demonstrates using POCO classes, in his words "as persistence ignorant as I can get", serializing entities with no EF references on the clients, yet not losing full change tracking on the client - and using the same domain classes on the client and the server (one could argue this last point as being not being a desirable goal - but it does have it's place).
So the million dollar question is: Does the Entity Framework replace the need for a Data Access Layer? If not, what should my Data Access Layer look like if I want to take advantage of the Entity Framework? In this multi-part series, I hope to explore my thoughts on this question. I don't think there is a single correct answer. Architecture is about trade offs and the choices you make will be based on your needs and context.
In this first post, I first provide some background on the notion of a Data Access Layer as a frame of reference, and specifically, identify the key goals and objectives of a Data Access Layer.
While Martin Fowler didn't invent the pattern of layering in enterprise applications, his Patterns of Enterprise Application Architecture is a must read on the topic. Our goals for a layered design (which may often need to be traded off against each other) should include:
- Changes to one part or layer of the system should have minimal impact on other layers of the system. This reduces the maintenance involved in unit testing, debugging, and fixing bugs and in general makes the architecture more flexible.
- Separation of concerns between user interface, business logic, and persistence (typically in a database) also increases flexibility, maintainability and reusability.
- Individual components should be cohesive and unrelated components should be loosely coupled. This should allow layers to be developed and maintained independently of each other using well-defined interfaces.
Now to be clear, I'm talking about a layer, not a tier. A tier is a node in a distributed system, of which may include one or more layers. But when I refer to a layer, I'm referring only to the logical separation of code that serves a single concern such as data access. It may or may not be deployed into a separate tier from the other layers of a system. We could then begin to fly off on tangential discussions of distributed systems and service oriented architecture, but I will do my best to keep this discussion focused on the notion of a layer. There are several layered application architectures, but almost all of them in some way include the notion of a Data Access Layer (DAL). The design of the DAL will be influenced should the application architecture include the distribution of the DAL into a separate tier.
In addition to the goals of any layer mentioned above, there are some design elements specific to a Data Access Layer common to the many layered architectures:
- A DAL in our software provides simplified access to data that is stored in some persisted fashion, typically a relational database. The DAL is utilized by other components of our software so those other areas of our software do not have to be overly concerned with the complexities of that data store.
- In object or component oriented systems, the DAL typically will populate objects, converting rows and their columns/fields into objects and their properties/attributes. this allows the rest of the software to work with data in an abstraction that is most suitable to it.
- A common purpose of the DAL is to provide a translation between the structure or schema of the store and the desired abstraction in our software. As is often the case, the schema of a relational database is optimized for performance and data integrity (i.e. 3rd normal form) but this structure does not always lend itself well to the conceptual view of the real world or the way a developer may want to work with the data in an application. A DAL should serve as a central place for mapping between these domains such as to increase the maintainability of the software and provide an isolation between changes in the storage schema and/or the domain of the application software. This may include the marshalling or coercing of differing data types between the store and the application software.
- Another frequent purpose of the DAL is to provide independence between the application logic and the storage system itself such that if required, the storage engine itself could be switched with an alternative with minimal impact to the application layer. This is a common scenario for commercial software products that must work with different vendors' database engines (i.e. MS SQL Server, IBM DB/2, Oracle, etc.). With this requirement, sometimes alternate DAL's are created for each store that can be swapped out easily. This is commonly referred to as Persistence Ignorance.
Getting a little more concrete, there are a host of other issues that also need to be considered in the implementation of a DAL:
- How will database connections be handled? How will there lifetime be managed? A DAL will have to consider the security model. Will individual users connect to the database using their own credentials? This maybe fine in a client-server architecture where the number of users is small. It may even be desirable in those situations where there is business logic and security enforced in the database itself through the use of stored procedures, triggers, etc. It may however run incongruent to the scalability requirements of a public facing web application with thousands of users. In these cases, a connection pool may be the desired approach.
- How will database transactions be handled? Will there be explicit database transactions managed by the data access layer or will automatic or implied transaction management systems such as COM+ Automatic Transactions, the Distributed Transaction Coordinator be used?
- How will concurrent access to data be managed? Most modern application architecture's will rely on an optimistic concurrency to improve scalability. Will it be the DAL's job to manage the original state of a row in this case? Can we take advantage of SQL Server's row version timestamp column or do we need to track every single column?
- Will we be using dynamic SQL or stored procedures to communicate with our database?
As you can see, there is much to consider just in generic terms, well before we start looking at specific business scenarios and the wacky database schemas that are in the wild. All of these things can and should influence the design of your data access layer and the technology you use to implement it. In terms of .NET, the Entity Framework is just one data access technology. MS has been so kind to bless us with many others such as Linq To SQL, DataReaders, DataAdapters & DataSets, and SQL XML. In addition, there are over 30 3rd party Object Relational Mapping tools available to choose from.
Ok, so if you're not familiar with the design goals of the Entity Framework (EF) you can read all about it here or watch a video interview on channel 9, with Pablo Castro, Britt Johnson, and Michael Pizzo. A year after that interview, they did a follow up interview here.
In the next post, I'll explore the idea of the Entity Framework replacing my data access layer and evaluate how this choice rates against the various objectives above. I'll then continue to explore alternative implementations for a DAL using the Entity Framework.
If you're thinking of heading down to Orlando June 3-6, 2008 - you can check out the list of sessions which has been recently posted here.
You also have the option of rating sessions that you might be interested in. I assume this is to help plan room sizes.
I'll be doing a breakout session called "Building Next Generation Data Access Layers with the ADO.NET Entity Framework" in the Architecture Track. I'm really looking forward to it. Hope to see you there.
Are you an architect or an aspiring architect interested in learning what's new this year for the MS platform?
On February 11th, 2008 come to the MS Canada Office in Mississauga and visit yours truly and some other dazzling speakers to learn more about Visual Studio 2008 and Windows Server 2008.
You can choose either the morning or afternoon session as your schedule permits. Only a 1/2 day out of your busy schedule and you'll know everything you need! Ok, well maybe not everything, but I hope that you'll be inspired to take the next steps in learning about technologies such as LINQ, Windows Communication Foundation and Windows Presentation Foundation and how you can make the most of these technologies in your applications.
Register Here.Technorati Tag
Last night I gave a presentation to the Toronto SharePoint Users Group
on using Visual Studio 2008 to build SharePoint Workflows. I also covered a little bit on LINQ to SharePoint and WCF/WF integration at the end. Attached are my slides. Enjoy.
This past Saturday, I gave a talk at the Toronto SharePoint Camp on building composite applications. I started talking in general requirements terms of why composite applications are useful, what they are, and what are the platform requirements - it naturally came down to a SharePoint demo - it's a great platform for building web based composite applications. The nice thing about SharePoint is that much of that work can be done in an ad hoc fashion. This means less plumbing code for us developers and we get to focus on solving business problems.
Some of the things I demonstrated are all available with Windows SharePoint Services (free). For example, Document Libraries and Custom lists, along with the excellent Outlook integration (including offline support) not to mention version control. Then we got into Workflow and integration with enterprise data with the Business Data Catalog of which requires the Microsoft Office SharePoint Server or MOSS 2007 which is not free (approx $5000), but a totally worthwhile investment. You can easily save the license fees several times over in reduced development effort. I also used SharePoint Designer which is about $200-300.
My slides and demo files are attached. Let me know if you have any questions. I've also included some demo script notes in the slide notes for those who asked.
Also, check out Rob Windsor's Pictures on Flickr of the event
This coming Thursday, Microsoft is hosting the annual Toronto Architect Forum at their offices in Mississauga. The target audience is architects that are *not* in the financial service industry. Here's the agenda:
|8:00 - 8:30 am
||Breakfast and Registration|
|8:30 - 9:00 am
||Welcome by Mark Relph|
|9:00 - 9:30 am
||Architectural Agility as Business Value, Dave Remmer|
|9:30 - 10:30 am
||Office Business Applications, Mike Walker|
|10:30 - 10:45 am
|10:45 - 12:00 pm
||Visual Studio 2008 “All Up”, Adam Gallant|
|12:00 - 1:00 pm
|1:00 - 2:15 pm
||Architectural Implications of LINQ, Barry Gervin|
|2:15 - 2:30 pm
|2:30 - 3:00 pm
||Project Experiences using AJAX, Amalan Ponnampalam|
|3:00 - 4:15 pm
||How to be an Effective Architect, Mohammad Akif|
|4:15 - 4:30 pm
||Wrap-up and Prize Draw|
As you can, I've secured the ever so popular "right after lunch" time slot. I don't know if there are detailed abstracts online for each session, but here is mine:
LINQ: Architectural Implications
Support for Language Integrated Query in the .NET 3.5 Framework promises to simplify and unify querying operations across object collections, relational data, DataSets and XML. The opportunity to simplify or even eliminate the notion of a data access layer is one many architects are considering. During this session we will quickly introduce the capabilities of LINQ, LINQ to SQL and the upcoming Entity Framework, and then discuss how this may affect the design of our data access logic moving forward.
Registration is still open - here.
Update - the event is for Architects not in the financial services industry (my mistake).
Slides from "Bridging SOA & BPM" SMART Event.
I guess by the very definition of an architect, you would have to have aspirational qualities. Mohammad Akif & and Dave Remmer, Architect Evangelists with Microsoft Canada are putting on a series of web casts just for you. Check them out....
Architecture 101 (Mohammad, May 24)
Architecture is the balance between art and engineering, it requires a certain mindset and approach to solving problems. Architects often function as a bridge between the business users and development groups and are increasingly being recognized as a critical community within organizations. Becoming an Architect can often translate in to an elevated status from a career stage perspective but it is hard to find prescriptive guidance around how to become an architect. Join Mohammad Akif for the first of a four part series focused on aspiring architects. During the Architecture 101 session we will discuss some key ideas around Architecture and define attributes of an architect.
Software development lifecycle and methodologies (Dave, May 31)
Over the years the various approaches teams have used to develop software have evolved. Join Dave Remmer in the second of a series focused on aspiring architects where we will discuss the various stages projects go through and sample some of the methodologies used by teams developing software. In this session we will compare and contrast the waterfall, agile, RUP, Scrum and MSF methodologies and how they are used within software projects.
Services orientation and other architectural paradigms (Dave, June 7)
One of the hottest topics in software architecture is the services oriented approach to building solutions and how this can provide agility, flexibility and reuse. Join Dave Remmer in the third of a series focused on aspiring architects where we will be looking at approaches to architecting software. This session will give an overall description of service orientation and how it differs from object oriented and component based architectures as well as a discussion of some of the organizational challenges teams experience when using a services oriented architecture.
Transitioning from a developer to an architect (Mohammad, June 14)
Are you a developer who would like to learn more about becoming an architect? Or how to get formally recognized as one (since you already wear the design and architecture hat along with the developer one)?. Join Mohammad Akif for the fourth and last part of the series focused on aspiring architects, during this session we will discuss how you can attain the skill set required to be an architect and sell yourself as an architect within your organization and industry. We will also provide a list of resources that you can use to continue the transition from a developer to an architect role.
Today I had the great pleasure of giving a talk to the graduating class of Conestoga College's "Computer Programmer/Analyst" program, and a few students from the Health Informatics degree program as well. I must admit that at first I struggled with what to talk to them about but when I thought about when I was a student, I remembered simply being eager to know anything more about the world outside the school walls. So I decided to just give them a glimpse of the world that I know best, namely the world of Software Architecture. Since that is primarily what I do, I decided to try to give them a feel for what Software Architecture is.
I have posted the slides from the talk here: http://objectsharp.com/cs/files/folders/37913/download.aspx, but bear in mind that, without the accompanying talk, the slides themselves offer very little. However, I thought I'd make them available in case any of the students wanted to look at them to remind them of what I talked about.
I thoroughly enjoyed the experience.