My Blogs

Windows Presentation Foundation (WPF) Development (4 of 4)

Sat, 31 Jul 2010 09:41:00 GMT

This is a series of article that define my conventions on how to do Windows Presentation Framework (WPF) development using Expression Blend and the ‘MVVM toolkit’.

Introduction
Windows Presentation Foundation (WPF) Conventions
Implementation using ‘MVVM Light’ toolkit
Sample application

More...

Windows Presentation Foundation (WPF) Development (3 of 4)

Sat, 31 Jul 2010 08:53:00 GMT

This is a series of article that define my conventions on how to do Windows Presentation Framework (WPF) development using Expression Blend and the ‘MVVM toolkit’.

Introduction
Windows Presentation Foundation (WPF) Conventions
Implementation using ‘MVVM Light’ toolkit
Sample application

More...

Windows Presentation Foundation (WPF) Development (2 of 4)

Fri, 30 Jul 2010 08:09:00 GMT

This is a series of article that define my conventions on how to do Windows Presentation Framework (WPF) development using Expression Blend and the ‘MVVM toolkit’.

Introduction
Windows Presentation Foundation (WPF) Conventions
Implementation using ‘MVVM Light’ toolkit
Sample application

More...

Windows Presentation Foundation (WPF) Development (1 of 4)

Fri, 30 Jul 2010 02:56:00 GMT

This is a series of article that define my conventions on how to do Windows Presentation Framework (WPF) development using Expression Blend and the ‘MVVM toolkit’.

Introduction
Windows Presentation Foundation (WPF) Conventions
Implementation using ‘MVVM Light’ toolkit
Sample application

More...

Entity Framework: First (unsuccessful) step with a 'Model Driven' design approach

webmaster@eccodynamics.net — Tue, 09 Jun 2009 09:43:00 GMT

As a believer in model-driven design, I got excited when Entity Framework released the new capability of using the model designer to design your domain model first. As a second step, it allows you then to create the database schema. So, needless to say I jumped into it and tried it out. My enthusiasm got a damper when I realized that the Beta version has still some serious problems. Nevertheless, I think it is the right way to go.

More...

CSS Fluid Design: 3-column layout 100% height

Wed, 27 May 2009 06:50:00 GMT

CSS is simple, isn't it? Then try this: I was looking to implement an application design which uses the full screen (regardless of end user's view port resolution) and has a simple 3 or 2 column layout. It has a header section, no footer, but the tricky part was that the columns have to fill down the whole lenght of the browser.
I needed three attempts and I read a whole CSS book (Fexible Web Design - Creating Liquid and Elastic Layouts with CSS) in between to get where I am today. You can download my example or you can try it yourself.

More...

Coding guidelines- business rules

renato.eccher@eccodynamics.net — Sun, 17 May 2009 19:40:00 GMT

We have seen (05/15/2009) that filters and validators make up the business rule set. Applications which have their business rule implementations scattered all around in the architecture are hard and costly to maintain. To avoid that, every project must defines guidelines for business rule implementations at the very beginning.

More...

Business requirements versus business rules

renato.eccher@eccodynamics.net — Sat, 16 May 2009 11:33:00 GMT

Business rules are probably ranked in the top-ten of most misunderstood terms in computer science. In order to understand what business rules are you have to understand what business applications are and how the software development process works.

More...

Component Architecture - part two: technology stack

renato.eccher@eccodynamics.net — Thu, 14 May 2009 08:09:00 GMT

In part one (5/12/2009), I defined the responsibilities of the components of a data driven application. In this second part, I will show in what layer of the application architecture these components live. In addition, I define the technologies used to implement these responsibilities which I will address in detail in later blogs entries.

More...

Component Architecture - part one: responsibilities

renato.eccher@eccodynamics.net — Wed, 13 May 2009 02:10:00 GMT

The component architecture defines the responsibilities of each layer or component of an application. Defining this at the beginning of a project, implementing accordingly and validating it through code reviews is the basis for maintainable applications. By not defining it at the beginning, you will have as many component architectures as you have programmers on your team over time.

More...