Logic Wiki - User contributions [en]

Senior Application Developer

2014-08-20T15:36:37Z

85.199.239.140: Created page with "Category:Extreme Programming Senior application developers manage teams of computer software engineers to create and update programs used by business professionals. They..."

[[Category:Extreme Programming]]

Senior application developers manage teams of computer software engineers to create and update programs used by business professionals. They must establish what a customer needs, delegate projects to team members and follow up to verify all projects are completed on time and as requested.

== Job Description for a Senior Application Developer ==
Senior application developers (SADs) work in the computer industry supervising other application and system developers. The U.S. Bureau of Labor Statistics (BLS) states that these computer application software engineers focus on the user's needs in regard to the functions of business-related computer software programs (www.bls.gov).

Working with individual clients or larger companies, SADs examine the company's goals and review the current technology to determine what upgrades can be made or what new programs should be installed to help improve efficiency. Since SADs act as supervisors, they often delegate the duties of upgrading and installing new systems to a team of application software engineers.

According to O*NET Online, SADs are engineer managers in charge of assigning projects to lower-level engineers (www.online.onetcenter.org). Usually SADs participate in the hiring process and routinely evaluate the progress of their team members.

== Job Duties of Senior Application Developers ==
SADs maintain the job duties of a supervisor as well as a lower-level application developer or engineer. These duties can include regular consultations with clients concerning software, creating new programs and testing newly installed programs to verify functionality.

The managerial side of being a SAD can include writing reports on team progress and presenting those reports to upper executive committees, per O*NET. Some SADs review budgetary issues and assist on negotiating contracts with new customers. SADs also make executive level decisions for their department, ensure company policies are being followed and counsel employees as needed.

== Requirements ==
Although software application engineers only require a bachelor's degree, according to the BLS, a senior-level position may require a master's degree in information technology or computer sciences. Combining a bachelor's degree with certification in computer languages and software programs may supplement a graduate degree for some SAD positions.

O*NET shows that this position requires at least five years experience in the technology industry with some experience in management. Most employers also require various levels of certification, especially related to software programs, according to the BLS. Many technology companies require SADs to know several programming languages, such as Java, HTML, C++ and Perl.

Razor

2014-08-15T12:57:06Z

85.199.239.140: Created page with "Category:MVC Category:ASP.NET Category:CSharp Category:TODO Razor is a template syntax that allows you to combine code and content in a fluid and expressive m..."

[[Category:MVC]]
[[Category:ASP.NET]]
[[Category:CSharp]]
[[Category:TODO]]

Razor is a template syntax that allows you to combine code and content in a fluid and expressive manner. Though it introduces a few symbols and keywords, Razor is not a new language. Instead, Razor lets you write code using languages you probably already know, such as C# or Visual Basic .NET.

<div>This page rendered at @DateTime.Now</div>

@if(User.IsAuthenticated)
{
<span>Hello, @User.Username!</span>
}
else
{
<span>Please @Html.ActionLink("log in")</span>
}

== Differentiating Code and Markup ==
Razor provides two ways to differentiate code from markup: code nuggets and code blocks.
=== Code Nuggets ===
Code nuggets are simple expressions that are evaluated and rendered inline. They can be mixed with text and look like this:

Not Logged In: @Html.ActionLink("Login", "Login")

The expression begins immediately after the @ symbol, and Razor is smart enough to know that the closing parenthesis indicates the end of this particular statement. The previous example will render this output:
Not Logged In: <a href="/Login">Login</a>

==== Explicit code nuggets ====
The explicit code nugget syntax (@( )) allows you to wrap a code statement, unambiguously marking the beginning and end of the statement.

=== Code Blocks ===
A code block is a section of the view that contains strictly code rather than a combi- nation of markup and code. Razor defines a code block as any section of a Razor template wrapped in @{ } characters. The @{ characters mark the beginning of the block, followed by any number of lines of code. The } character closes the code block. Keep in mind that the code within a code block is not like code in a code nugget. It is fully-formed code that must follow the rules of the current language; for example, each line of code written in C# must include a semicolon (;) at the end, just as if it lived within a class in a .cs file. Here is an example of a typical code block:

@{
LayoutPage = "~/Views/Shared/_Layout.cshtml";
View.Title = "Product Details for " + Model.ProductName;
}

== The @: character sequence ==
The @: character sequence The @: character sequence indicates a transition, telling Razor to assume that the con- tent that follows the sequence is content, not code

@if(User.IsAuthenticated)
{
@:Hello, @User.Name!
}
else
{
@:Please login
}

== The <text> block ==
The <text> block is an alternative to the @: character sequence that allows you to denote that an entire portion of a template is content.

@if(!User.IsAuthenticated)
{
<text>
Guests are not allowed to view this content.
Please @Html.ActionLink("login", "Login") to view.
</text>
}

== Comments ==
@* *@

== Organizing Razor Templates ==
=== Layouts ===
A layout template typically includes the main markup (scripts, CSS stylesheets, and structural HTML elements, such as navigation and content containers), specifying lo- cations within the markup in which pages can define content. Each page in the site refers to this layout, including only the content within the locations the layout has indicated.

Take a look at a typical Razor layout file (_Layout.cshtml):
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>@View.Title</title>
</head>
<body>
<div class="header">
@RenderSection("Header")
</div>
@RenderBody()
<div class="footer">
@RenderSection("Footer")
</div>
</body>
</html>

Once a Razor layout is defined, pages reference the layout and supply content for the sections defined within the layout. The following is a basic content page that refers to the previously defined _Layout.cshtml file:
@{ Layout = "~/_Layout.cshtml"; }
@section Header {
<h1>My Blog<h1>
}
@section Footer {
Copyright 2011
}
<div class="main">
This is the main content.
</div>

=== Sections ===
Syntax :
@section [Section Name]
{
[ Razor content, code, and markup ]
}
==== IsSectionDefined ====
Determines whether a section of a given name is defined in the content view.
@RenderBody()
@if(IsSectionDefined("Footer"))
{
<div class="footer">
@RenderSection("Footer", required: false)
</div>
}

=== Nested Layouts ===
Layouts can also be “nested.” A nested layout is any layout that refers to another, outer layout.

=== Partial Views ===
RenderPage("Posts/_Post.cshtml", new { Post = post })

=== Razor Helpers ===

Fowler’s Enterprise Design Patterns

2014-08-15T12:11:51Z

85.199.239.140:

[[Category:Design Patterns]]
[[Category:Extreme Programming]]
Martin Fowler’s ''Patterns of Enterprise Application Architecture'' book is a best practice and patterns reference for building enterprise-level applications. As with the GoF patterns book, experienced developers will no doubt already be following many of the catalogued patterns. The value in Fowler’s work, however, is the categorization of these patterns along with a common language for describing them. The book is split into two sections. The first half deals with n-tier applications and the organiz- ing of data access, middleware, and presentation layers. The second half is a patterns reference rather like the GoF patterns book but more implementation specific.

Throughout this book, you will be looking at the ASP.NET implementations of Fowler’s patterns. The following sections examine what the rest of the book will tackle.

=== Layering ===
Chapter 3 covers the options at your disposal to layer an enterprise ASP.NET application. You will look at the problems with the traditional code behind the model of web forms, and how to separate the concerns of presentation, business logic, and data access with a traditional layered approach.

=== Domain logic Patterns ===
Chapter 4 examines three popular methods for organizing your business logic: Transaction Script, Active Record, and Domain Model.

==== Transaction script ====
Transaction Script is the organization of business logic in a linear, procedural fashion. It maps fine- grained business use cases to fine-grained methods.

==== Active record ====
Active Record organizes business logic in a way that closely matches the underlying data structure, namely an object that represents a row in a table.

==== Domain Model ====
The Domain Model pattern is an abstraction of real domain objects. Both data and behavior are modeled. Complex relationships between objects can exist that match the real domain. You will look at how to use each of these patterns in ASP.NET and when it is appropriate to choose one pattern over another.

Chapters are reference to "'''The Pattern for Successful applications'''"

Common Design Principles

2014-08-15T10:59:56Z

85.199.239.140: Created page with "Category:Extreme Programming Category:Design Patterns == Common Design Principles == There are a number of common design principles that, like design patterns, have..."

[[Category:Extreme Programming]]
[[Category:Design Patterns]]

== Common Design Principles ==

There are a number of common design principles that, like design patterns, have become best practice over the years and helped to form a foundation onto which enterprise-level and maintainable software can be built. The following sections preview some of the more widely known principles.

=== Keep it simple stupid (Kiss) ===
An all-too-common issue in software programming is the need to overcomplicate a solution. The goal of the KISS principle is concerned with the need to keep code simple but not simplistic, thus avoiding any unnecessary complexities.

=== Don’t repeat Yourself (DrY) ===
The DRY principle aims to avoiding repetition of any part of a system by abstracting out things that are common and placing those things in a single location. This principle is not only concerned with code but any logic that is duplicated in a system; ultimately there should only be one representation for every piece of knowledge in a system.

=== Tell, Don’t ask ===
The Tell, Don’t Ask principle is closely aligned with encapsulation and the assigning of responsi- bilities to their correct classes. The principle states that you should to tell objects what actions you want them to perform rather than asking questions about the state of the object and then making a decision yourself on what action you want to perform. This helps to align the responsibilities and avoid tight coupling between classes.

=== You ain’t Gonna need it (YaGni) ===
The YAGNI principle refers to the need to only include functionality that is necessary for the applica- tion and put off any temptation to add other features that you may think you need. A design meth- odology that adheres to YAGNI is test-driven development (TDD). TDD is all about writing tests that prove the functionality of a system and then writing only the code to get the test to pass. TDD is discussed a little later in this chapter.

=== Separation of Concerns (soC) ===
SoC is the process of dissecting a piece of software into distinct features that encapsulate unique behav- ior and data that can be used by other classes. Generally, a concern represents a feature or behavior of a class. The act of separating a program into discrete responsibilities significantly increases code reuse, maintenance, and testability. The remainder of this book refers back to these principles so you can see how they are implemented and help form clean and maintainable object-oriented systems. The next group of design principles you will look at were collected together under the grouping of the S.O.L.I.D. design principles.

Repository Pattern

2014-08-12T07:16:19Z

85.199.239.140: CRUD,

[[Category:Design Patterns]]
[[Category:CSharp]]
[[Category:ASP.NET]]
Reporsitory pattern is a layer between application and data storage. With this pattern application doesn't need to know how to delete, update or write data to database.

Sample pattern :

using System;
using System.Linq;
using System.Linq.Expressions;
namespace Remondo.Database.Repositories
{
public interface IRepository<T>
{
void Insert(T entity);
void Delete(T entity);
IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate);
IQueryable<T> GetAll();
T GetById(int id);
}
}
The generic GetById() method explicitly needs all our entities to implement the IEntity interface. This is because we need them to provide us with an Id property to make our generic search for a specific Id possible.

namespace Remondo.Database
{
public interface IEntity
{
int ID { get; }
}
}

Since we already have LINQ to SQL entities with an Id property, declaring the IEntity interface is sufficient. Since these are partial classes, they will not be overridden by LINQ to SQL code generation tools.

namespace Remondo.Database
{
partial class City : IEntity
{
}

partial class Hotel : IEntity
{
}
}

Sample Implementation

using System;
using System.Data.Entity;
using System.Linq;
using System.Linq.Expressions;

namespace Remondo.Database.Repositories
{
public class Repository<T> : IRepository<T> where T : class
{
protected DbSet<T> DbSet;

public Repository(DbContext dataContext)
{
DbSet = dataContext.Set<T>();
}

#region IRepository<T> Members

public void Insert(T entity)
{
DbSet.Add(entity);
}

public void Delete(T entity)
{
DbSet.Remove(entity);
}

public IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate)
{
return DbSet.Where(predicate);
}

public IQueryable<T> GetAll()
{
return DbSet;
}

public T GetById(int id)
{
return DbSet.Find(id);
}
#endregion
}
}