Application Layers

Software applications are based on layers and the communication between them, so the main task in the design of an application architecture will be the identification and creation of layers and then to specify a communication language and set the rules and guidelines of the interaction between these layers.

Additional info available in the full article here: http://www.jaftalks.com/Home/Show/Application%20Layers

SilverLight 4.0 New Functionality – Great Features

Hello,

All developers who use SilverLight 3, can feel the limitations in the production of many critical issues and functionalities, especially when you try to create printable reports, or to show and manipulate Right-to-Left languages data, SilverLight 3 don’t allow the use of right click menu context, in addition to a good number of other limitations that Microsoft took into consideration in the beta version of SilverLight 4.

 

additional info: http://www.jaftalks.com/Home/Show/SilverLight%204.0%20New%20Functionality

Creational design patterns

This design patterns is all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

Creational patterns become important as systems evolve to depend more on object composition than class inheritance.

• Abstract Factory

Creates an instance of several families of classes

• Builder

Separates object construction from its representation

• Factory Method

Creates an instance of several derived classes

• Object Pool

Avoid expensive acquisition and release of resources by recycling objects that are no longer in use

• Prototype

A fully initialized instance to be copied or cloned

• Singleton

A class of which only a single instance can exist

Soon I’ll start posting detailed description of each one o these design paters.

Kentico vs. DNN – CMS comparison

Kentico vs. DNN – CMS comparison

I’ve worked a little with DotNetNuke .Net CMS but I don’t have a perfect experience with it, while I’ve developed a portal using Kentico. There are pros and cons for both of them.

Pros

1. Documentation for some webparts (module equivalents)
2. Excellent backend for administration
3. Use of webparts making code reuse pretty easy (change inherits and you’re there).
4. Good useful built in components (logging, analytics…)
   • After sales support is excellent, but before sale NO Support

Cons

1. Lack of community: their forums are very small, with little in the way of programming questions and answers
   • But they reply to all questions
2. Few 3rd party components
   • But developers have the ability to add webparts
3. It costs money – $1000/site, and to use e-commerce you’ll pay more.
   • They argue, that they have a fully supportable CMS
4. Poor development environment
   • localhost version has 30 day timeout, ecommerce version limited to 10 products etc.
5. Odd object model
   • You need to create document types, documents,document templates and assign to a menuid etc.
6. Requires full trust for some configurations so will not work on all hosting providers and is inherently less secure than a medium trust site (such as dotnetnuke)
7. The user who will create the templates should have technical skills

Web Content Management System (CMS) and Application Development Platform for Microsoft .NET.

DNN Community Edition is free, but other Editions are payed.

Pros

1. Wide spread  in the internet
   • More documentation and discussion
2. Use of third party components making the sites rich
3. Free and low costs
4. Open Source
5. medium trust site, can be hosted anywhere
6. a non technical can handle all the sites

Cons

1. DNN has an advertising add-ons – to manage advertising on the site, Kentico don’t have one.
2. Bad admin user experience
3. Hard to make it your own
4. E-commerce is not fully supported
5. There is a lot of modules, but not all are free
6. Costing based on needs – no fixed prices
7. In general I’ve found it much tougher to work with Kentico than dotnetnuke. The backend is very good for site administrators to use, so if you’re not doing a lot of development I think it’s a reasonable choice, but if you have a lot of development dotnetnuke open source is a better choice.
8. Finally it depends of the project scope and budget.

DotNetNuke resources:

Site: http://www.dotnetnuke.com

Versions Comparison: http://www.dotnetnuke.com/Products/ProfessionalEdition/EditionComparison/tabid/1250/Default.aspx

Modules magazine: http://www.snowcovered.com/

Kentico resources:

Site: http://www.kentico.com/

Pricing: http://www.kentico.com/Buy.aspx

Versions comparison: http://www.kentico.com/cms-asp-net-features/Feature-Matrix.aspx

Introduction About MVVM – Model View ViewModel Design Pattern

Last week was my first presentation while playing the Solution Architect Role in ArabiaGIS, so I tried to start with an introduction to design patterns, and my first subject was the Model-View-ViewModel design pattern. in the presentation I tried to introduce the design pattern concept, showing its importance and the goals off applying it.

for more info : http://www.jaftalks.com/Home/Show/%20MVVM%20%E2%80%93%20Model%20View%20ViewModel

Introduction To ASP.NET MVC Design Pattern

I was conducting a presentation about ASP.NET MVC design pattern, and the importance of using such pattern in order to enhance the asp.net web application structure and make easier their maintainability and testability, and to show the importance of putting rules and guidelines in place of letting the developer decides how to implement the separation of concerns.

for more  info : http://www.jaftalks.com/Home/Show/ASP.NET%20MVC

Uses of Design Patterns

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn’t require specifics tied to a particular problem.

In addition, patterns allow developers to communicate using well-known, well understood names for software interactions.

Describing Design Patterns

Part of the idea of Design Patterns is that patterns have a certain literary form. In the GoF book, patterns typically have these (major) elements:

Name

A good name is vital, because it will become part of your design vocabulary.

Intent

A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?

Motivation

A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.

Applicability

What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations?

Structure

A graphical representation of the classes in the pattern.

Participants

The classes and/or objects participating in the design pattern and their responsibilities.

Collaborations

How the participants collaborate to carry out their responsibilities.

Consequences

How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?

Implementation

What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

Sample Code

Code fragments that illustrate how you might implement the pattern.

Known Uses

Examples of the pattern found in real systems.

Related Patterns

What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

What is a Design Pattern?

A pattern is a description of a common problem and a likely solution, based on experience with similar situations.

Wikipedia

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”.

A Pattern Language, 1977

Architect and Software Engineer

The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions.

 Brad Appleton

In general, a pattern has four essential elements:

1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two (ex. MVC).
2. The problem describes when to apply the pattern. It explains the problem and its context. (ex. Separation of concerns)
3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
4. The consequences are the results and trade-offs of applying the pattern. The consequences of a pattern include its impact on a system’s flexibility, extensibility, or portability.

Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.