Modern UI aka Metro


Hi Guys,

 

For Accountable, i have decided to use Microsoft’s Modern UI (No more Metro) for the design. After careful consideration I have gone with Metro UI CSS instead of Code52’s Metro.css for the sole reason I was having trouble with MVC4’s bundling feature on LESS files which is what Metro.css uses.

 

Metro UI CSS though is easy to implement. Once I have completed Accountable, i will create a MVC4 Project Template and some custon scaffolding and T4 Templates that uses the custom CSS and Javascript that it utilises so anyone can pick it up without the pain of manually amending views CSS etc.

 

Here are some images so far. Some of the styling is turd at the moment and will improve, but this is just a glimpse of what is to come:

 

This slideshow requires JavaScript.

Enhanced by Zemanta

Repository and Unit Of Work Design Pattern– ASP.NET MVC


Hello! There are two design patterns that I’m going to speak about today, which have been covered loads online and in various books, but I’m going to cover them quickly here:

 

Repository Pattern

 

Quite simply this is a pattern to separate all the data access logic from your application into separate container classes. It is good practise to create Repositories for each Domain area of your application and separate data access concerns, like CRUD operations within these. For e.g. I have the following Domains within my application Accountable (A personal Accounts App):

 

  • LedgerUser – User details
  • LedgerPeriod – Date from/to for each Accounting period defined by the LedgerUser
  • LedgerTransaction – Ledger Transactions that occur each Ledger Period.
  • Many more….

‘I’m not going to go into massive detail, but each Repository of each domain would have the following methods which are generally found in data access:

 

  • Create – Create new records
  • Update – Update existing records
  • Delete – Delete existing records
  • Find – Find records

Do design your Data Source correctly then apply the Repository classes to these. So this should make you think There is a lot of duplicate code here…..”  What do we do in these cases? We write some generic Interfaces to impose some rules on how our Repositories should behave. Please raise your classes (get it…?!) to IRepository:

 

public interface IRepository<TEntity> 
{
    void Create(TEntity entity);
    void Update(TEntity entity);
    void Delete(TEntity entity);
    IQueryable<TEntity> Find(Expression<Func<TEntity, bool>> predicate);
    IQueryable<TEntity> FindAll();
    TEntity FindById(Guid id);
    

}

 

 

See we have used IQueryable so that we can use other awesome chained LINQ methods (like OrderBy).

 

So this all lovely, but now onto the nitty gritty, taking that interface and applying it to a concrete example. Because I’m using EF a lot at the moment, i have written a EntityFrameworkRepository example using DbContext and Dbset:

 

    public class EntityFrameworkRepository<T> : IRepository<T> 
        where T : class, IRepositoryEntity
    {
        internal DbContext context;
        internal DbSet<T> dbSet;

        /// <summary>
        /// Default constructor.
        /// </summary>
        /// <param name="context"></param>
        public EntityFrameworkRepository(DbContext context)
        {
            this.context = context;
            this.dbSet = context.Set<T>();
        }

        public void Create(T entity)
        {
            dbSet.Add(entity);
        }

        public void Update(T entity)
        {
            dbSet.Attach(entity);
            context.Entry(entity).State = EntityState.Modified;
        }

        public void Delete (T entity)
        {
            if (context.Entry(entity).State == EntityState.Detached)
            {
                dbSet.Attach(entity);
            }
            dbSet.Remove(entity);

        }

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

        public T FindById(Guid id)
        {
            
            return dbSet.Single(o => o.id == id);
        }

        public IQueryable<T> FindAll()
        {
            return dbSet;
        }


        
    }
}

 

As you can see this class also implements IRepositoryEntity, which is an idea I stole off the Pluralsight video I watched, whereby in our IRepository interface where have a FindById method. This is presuming that the Entity in question using id within its design, which all my Entities do, so I’m safe to enforce this:

 

 

public interface IRepositoryEntity
{

    Guid id { get; }

}

 

 

 

Unit of Work

 

 

This is all nice and lovely but where is the data persistence? If you look closely and without just copy & pasting these examples, you will see in the Repository interfaces and concrete implementations, there are “commit” or “save” methods. Why? Well we can abstract this further into a Unit Of Work pattern which will:

  • Handle persistence
  • Share the context within Repositories

This will allow one context to be used without the Repositories having to know about each other or their respective Dbcontext’s. Now because we are good programmers we should first design the interface, IUnitOfWork:

public interface IUnitOfWork : IDisposable
{


    void Save();


}

 

Is that it?! Well yes. What i would like to do in the future is have a GenericCollectionRepository within the Unit Of Work concrete implementations, but i will refactor that in at a later date. So following the pattern of EF, this is the EntityFrameworkUnitOfWork:

 

public class EntityFrameworkUnitOfWork : IUnitOfWork
    {
        private AccountsContext context = new AccountsContext();
        internal IRepository<LedgerAccount> account;
        internal IRepository<LedgerUser> user;
        internal IRepository<UserType> userType;
        internal IRepository<Image> image;
        internal IRepository<SystemReference> systemReference;
        internal IRepository<LedgerService> ledgerService;

       


        public IRepository<LedgerAccount> Account
        {
            get
            {
                if (account == null)
                {
                    account = new 
EntityFrameworkRepository<LedgerAccount>(context); } return account; } } public IRepository<LedgerUser> User { get { if (user == null) { user = new EntityFrameworkRepository<LedgerUser>(context); } return user; } } public IRepository<UserType> UserType { get { if (userType == null) { userType = new EntityFrameworkRepository<UserType>(context); } return userType; } } public IRepository<Image> Image { get { if (image == null) { image = new EntityFrameworkRepository<Image>(context); } return image; } } public IRepository<SystemReference> SystemReference { get { if (systemReference == null) { systemReference = new
EntityFrameworkRepository<SystemReference>(context); } return systemReference; } } public IRepository<LedgerService> LedgerService { get { if (ledgerService == null) { ledgerService = new
EntityFrameworkRepository<LedgerService>(context); } return ledgerService; } } public void Save() { context.SaveChanges(); } private bool disposed = false; protected virtual void Dispose(bool disposing) { if (!this.disposed) { if (disposing) { context.Dispose(); } } this.disposed = true; } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } }

The beautify of this approach is the reduction in business logic within your Controller of your MVC Application and reducing "controller bloat”.

 

Here is an example of the both patterns working in harmony:

 

 

public class LedgerUserController : Controller
   {
             
       private EntityFrameworkUnitOfWork unitOfWork = 
new EntityFrameworkUnitOfWork(); // // GET: /LedgerUser/Details/5 public ActionResult Details(Guid id) { LedgerUserViewModel viewModel = new LedgerUserViewModel(); UserType userType = new UserType(); try { viewModel.LedgerUser = unitOfWork.User.FindById(id); viewModel.UserType = unitOfWork.UserType.FindAll() .SingleOrDefault
(u => u.id == viewModel.LedgerUser.UserTypeId) .Description; viewModel.UniqueKey = viewModel.LedgerUser.id.ToString(); return View(viewModel); } catch (ArgumentNullException ex) { Console.WriteLine("ArgumentNullException " + ex.ToString()); } catch (InvalidOperationException ex) { Console.WriteLine("InvalidOperationException " + ex.ToString()); } return RedirectToAction("Index", "Home"); } }

 

All my controller is doing is what is was designed to, setting up the views data ready for rendering.

 

I know the code on these sites isnt the best, but i want to create a github repo of it soon. Watch this space! Smile

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enhanced by Zemanta

First look at ASP.NET MVC 4 Templates (via Hrichi Mohamed The .net Passion)


I’m definitely doing to have to check out ASP.NET MVC4 soon…..

First look at ASP.NET MVC 4 Templates Source : dotnetexpertguide With release of ASP.NET MVC 4 Developer Preview, ASP.NET MVC team introduces a new default project template for MVC 4. New template has following improvements. Cosmetic Improvements New MVC 4 project template has cosmetic improvements prior to MVC 3 project template. And it will help community to create good looking modern websites with the default template itself without investing more in template designing. Adaptive R … Read More

via Hrichi Mohamed The .net Passion