Developer roadmap - 2. Architecture improvements. Your thoughts.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
13 years ago
Castle Windsor or Microsoft Unity would be fine as IoC containers, except I caution the slower moving Microsoft offering.

MVC is your best bet with either the Spark View Engine or Microsoft's Razor

Consider MEF for making the app plug-in capable.

And, yes, get yourselves some licenses for JetBrains ReSharper and clean up some of the code.
13 years ago
thought wrote:
Use lucene.net for search - I have the code for this should you want it.

Sure, you're always welcome to share the source code
13 years ago
1. Usage of IoC/DI pattern - complete.
4. 'Pass entities as parameters to Manager methods' - complete

You're welcome to get the latest source code on CodePlex and let me know your thoughts or any further suggestions.
13 years ago
I found that passing values instead of entities made adding and updating entities more flexible.

What prompted you to change it to entities instead of values?
13 years ago
deccks wrote:
What prompted you to change it to entities instead of values?

It can really simplify further developement (e.g. adding a new property to an entity). Now you can pass the entire entity as when you update the entity (e.g. add or remove new properties) you do not have to update all your method calls. And methods with long parameter chains (e.g. OrderManager.InsertOrder method had about 50 parameters) are bad.
13 years ago
Since you put it that way, it does make more sense to pass entities instead of values.
13 years ago
Architecture improvements:
...
7. Repository pattern
8. Entities should be persistence ignorant. They should not depend on managers/services (remove custom properties).


Performance optimization:
...
5. Use lucene.net for search (Thanks, Will)
13 years ago
As for repository pattern. Should we create a generic repository (in this case we'll be using IRepository<Product> or IRepository<Category>)? Or should we create a repository for each service (in this case we'll be using IProductRepository or ICategoryRepository? What do you think?

BTW, if somebody is interested a generic repositry implementation is below
namespace NopSolutions.NopCommerce.BusinessLogic.Data
{
    /// <summary>
    /// Repository
    /// </summary>
    public partial interface IRepository<T> where T : BaseEntity
    {
        T GetById(object id);
        void Insert(T entity);
        void Update(T entity);
        void Delete(T entity);

        IQueryable<T> Table { get; }
    }

    /// <summary>
    /// Repository
    /// </summary>
    public partial class EFRepository<T> : IRepository<T> where T : BaseEntity
    {
        #region Fields

        /// <summary>
        /// Object context
        /// </summary>
        protected readonly NopObjectContext _context;

        protected ObjectSet<T> _entities;
        #endregion

        #region Ctor

        /// <summary>
        /// Ctor
        /// </summary>
        /// <param name="context">Object context</param>
        public EFRepository(NopObjectContext context)
        {
            this._context = context;
            this._entities = this._context.CreateObjectSet<T>();
        }

        #endregion

        #region Methods

        public virtual T GetById(object id)
        {
            if (id == null)
                return null;
            EntityKey key = this._entities.BuildEntityKey(id);
            object result = null;
            if (this._context.TryGetObjectByKey(key, out result))
                return (T)result;
            else
                return null;
        }

        public virtual void Insert(T entity)
        {
            if (entity == null)
                throw new ArgumentNullException("entity");

            this._entities.AddObject(entity);
            this._context.SaveChanges();
        }

        public virtual void Update(T entity)
        {
            if (entity == null)
                throw new ArgumentNullException("entity");

            if (!this._context.IsAttached(entity))
                this._entities.Attach(entity);

            this._context.SaveChanges();
        }

        public virtual void Delete(T entity)
        {
            if (entity == null)
                throw new ArgumentNullException("entity");

            if (!this._context.IsAttached(entity))
                this._entities.Attach(entity);
            this._context.DeleteObject(entity);
            this._context.SaveChanges();
        }

        #endregion

        #region Porperties

        public virtual IQueryable<T> Table
        {
            get
            {
                return this._entities;
            }
        }

        #endregion
    }
}
13 years ago
nopCommerce team | a.m. wrote:
As for repository pattern. Should we create a generic repository (in this case we'll be using IRepository<Product> or IRepository<Category>)? Or should we create a repository for each service (in this case we'll be using IProductRepository or ICategoryRepository? What do you think


Maybe take a look at the Castle Project's implementation of ActiveRecord.  This looks very similar.  Hate for you to reinvent the wheel.  Behind active record is just NHibernate, so what you're doing seems similar with EF behind it.
13 years ago
nopCommerce team | a.m. wrote:
As for repository pattern. Should we create a generic repository (in this case we'll be using IRepository<Product> or IRepository<Category>)? Or should we create a repository for each service (in this case we'll be using IProductRepository or ICategoryRepository? What do you think?


Are there any advantages or disadvantages to using one or the other?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.