 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Microsoft .Net Development News > Microsoft's Patterns & Practices Summit 2007: Development Day |
| |
|
|
|
|
| Microsoft .Net Development News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The latest Patterns & Practices Summit hit the conference center on the Microsoft campus. Each day had its own theme -- architecture, agile, development, software factories and applications. The report that follows focuses on the summit's development day. Why Ruby? John Lam kicked things off with a look at IronRuby, which is an open-source implementation of Ruby that runs .NET objects.
Lam identified three goals for IronRuby. The first is to be as compatible to Ruby as possible. The second is to peacefully coexist with the .NET Framework and, as a result, allow .NET to interoperate with the Mac, via Silverlight, and with Linux, via Mono. The third is to achieve acceptable performance -- that is, faster that it currently runs and with additional features.
Lam then demonstrated a bit of IronRuby's potential. In one scenario, he showed the audience how to build IronRuby class libraries. This involved adding classes and then marking constructor methods, which, like C# 3.0 extension methods, are static.
The Right Tools for the Right Job
"I don't know about you, but I feel utterly overwhelmed at the technology being thrown at us," Rockford Lhotka said at the beginning of his talk. "The only way I feel I can maintain any sort of sanity is to plug the new technology into an architectural framework."
At that, Lhotka launched a discussion of where and how it is best to use object-oriented design, service-oriented design or workflow design.
Object-oriented design is essentially message-based communication between objects, he said. It tends not to fit within a distributed computing model without a bit of planning. Service-oriented design, meanwhile, offers loosely coupled interactions between services that lack tiers. (Think of the basic tiers of an application -- the presentation, UI, business, data access and database layers.) This provides a nice, non-deterministic way to model how applications, and the world, tend to operate, and it is cross-platform and -language. On the other hand, Lhotka noted, both the concept and the tools are immature. Workflow design, finally, represents an orchestration of ordered activities that are designed in terms of input and output. This is not a new concept per se -- remember poster-sized flowcharts? -- but mastering it requires architects to unlearn object-oriented and event-driven programming, Lhotka said. Designing for Workflow Picking up where Lhotka left off, Ted Neward offered some "proto-patterns and proto-practices" for workflow design -- so described because there is no critical mass rallying around Windows Workflow Foundation yet. Neward first identified four goals of workflow design.
He then offered seven ruminations on the subject.
The Future of Model-Based Design David Trowbridge and Suhail Dutta focused primarily on Microsoft's plans for the role of modeling in Rosario, the version of Visual Studio Team System coming out after VS 2008. Rosario includes a logical class designer and a sequence designer, it supports Domain Specific Languages and those DSLs wrap around tool adaptors for a nice, loosely coupled interface. All this functionality can be used in standalone applications, Trowbridge said, or it can be used in a software factory. The duo also demoed Progression, which is the code name for a tool that aims to bridge the gap between architecture and development -- the former focusing on requirements and models, the latter on refactoring, visualizing, filtering and analyzing code. In Progression, architects can organize the components of a solution by namespaces and classes, links the references among all the classes and identify so-called "hubs," or important pieces of code on which numerous classes rely. Dependency Injection Frameworks Through dependency injection, objects that need to find each other, well, find each other. It works thanks to what Peter Provost described as the Hollywood Principle: "Don't call me. I'll call you."
Dependencies can be provided several ways -- through an interface and a contract, via setter methods, via constructor parameters or through method injections. These processes promote flexible code that is easy to test, maintain and reuse, but, Provost noted, they do lend themselves to the creation of lots and lots of objects. Enter ObjectBuilder. This runtime framework for building dependency injection systems will manage the way objects are built up. The Event Broker, for example, lets an object raise an event and then pass data along with it, while the Interceptor, as Scott Densmore put it, allows the Rebel Forces to get in the way of the Death Star's method call to destroy Alderaan. Enterprise Library Devolved Densmore returned to the dais to discuss the Enterprise Library, which is a collection of application blocks. The Enterprise Library Factory, meanwhile, is essentially a modified version of the dependency injection container and is used by all other factories. Configuration of an application's plug-ins, Densmore said, boils down to the container in which they are found and not the library. This means configuration should be easy to do without changing code. The Future of Design Patterns Much more was said during this hour-long panel discussion than can be reported here. Stay tuned for a full-fledged, honest-to-goodness story on future of Microsoft's Patterns and Practices program in the next few days.
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
