1

I am new to nopCommerce and ecommerce in general but I am involved in an ecommerce project. Now from my past experiences with RavenDB (which mostly were absolutely pleasant) and based on the needs of the business (fast changes with awkward business workflows) It seemed to be an appealing option to have RavenDB handling all sort of things related to the database.

I do not understand design and architecture of nopCommerce fully so I did not reach to a conclusion on how to factor data parts, since it seems the services layer actually does not abstract data-layer concepts away; like bringing in EF working model to other layers.

I have found another project which used NuDB as it's database as a nopCommerce fork. But it did not help because NuDB still has the feeling of a RDBMS and is not as different as RavenDB.

Now first how can I learn about the internals of nopCommerce (other than investigating the code)? It's workflows? It's conventions?

Second has anyone tried something similar before with a NoSQL database (say like MongoDB or RavenDB)? Is it possible to achieve this in a 1 (~2) month time frame?

Thanks in advance;

1

I've tried both MongoDB and RavenDB for NopCommerce's DB. However, as Matt said, it's not a good idea. Here are some reasons:

  1. The shortest way is repository pattern, an anti-fan of RavenDB. It took me about 2 weeks.
  2. The search function of Nop is optimized for SQL. Raven can do it better and more beautiful, but you must change many methods of Nop.
  3. All paging and sorting functions will be rewritten. To change the data layer, you'll have to change a half of the business layer, too!
| improve this answer | |
3

I have worked with both, and while it is possible it is certainly not recommended.

Systems that are designed around relational databases rarely can just be converted directly over to non-relational databases. There are many different patterns to use in order to achieve efficiency.

For example, in a relational database, you might have two tables that are joined with a one-to-many relationship, such as an Order and its OrderLineItems. This is very common in relational database design. However, it is completely undesired in a document database like RavenDB. Instead, you would model an entire document with all of it's children as a single "Aggregate Root". An Order and all of its OrderLineItems would be in one document.

Switching out storage engines via a repository interface may sound like a good idea, but in practice one usually finds it to be impractical.

| improve this answer | |
2

Now first how can I learn about the internals of nopCommerce (other than investigating the code)? It's workflows? It's conventions?

Well, there's always the documentation, but there's really no better way than reading the source code. The nopCommerce source code is organized fairly well, so it shouldn't be too hard.

Second has anyone tried something similar before with a NoSQL database (say like MongoDB or RavenDB)? Is it possible to achieve this in a 1 (~2) month time frame?

I have not tried this, nor do I know anybody who has. However, just a cursory look at the code shows that the data access strategy is pretty strongly structured around the Repository pattern using Entity Framework.

http://www.nopcommerce.com/docs/71/source-code-organization-architecture-of-nopcommerce.aspx

The Nop.Data project contains a set of classes and functions for reading from and writing to a database or other data store. It helps separate data-access logic from your business objects. nopCommerce uses the Entity Framework (EF) Code-First approach. It allows you to define entities in the source code (all core entities are defined into Nop.Core project), and then get EF to generate the database from that. That's why it's called Code-First. You can then query your objects using LINQ, which gets translated to SQL behind the scenes and executed against the database.

I would say that converting to a NoSQL back-end would probably require some significant effort. There have been other SO posts discussing using RavenDb with the repository pattern. Can it be done? Sure. Can it be done in a month or two? Maybe, but it's impossible to say without knowing a lot of your specific situation's details.

| improve this answer | |
  • 1
    There is already one such commercial integration exists that integrate Apache Solr with nopCommerce. More information is available at nopaccelerate.com – Krunal Oct 16 '13 at 5:24
1

Whoa, slow down, you never just swap out a database. That is extremely risky especially if the database is already in production. And converting from relational to nosql can be time consuming as things won't match up exactly. Your reason seems to be that you prefer the one you are used to which is a horribly invalid reason for the amount of risk you are taking by converting the database.

Nor is this a question for strangers on the Internet, if you propose to do such a thing, your business leaders need to know in advance and with much discussion as to the time and the risk and the benefits. It is NOT your call, it is a management decision.

But further, you will need to determine if you need to convert existing data and look for any existing other things which might use the database backend besides your application such as reporting applications or data imports. It might even be set up specifically to follow rules which are required by auditors or credit card processors and which may preclude teh use of nosql.

I wouldn't even want to take on converting an Oracle database to SQl server or vice versa without at least a year in the project plan let alone convert from relational to nonrelational.

However, consider that new functionality could use the nosql approach if it is approved in advance, for things that cannot easily be defined in advance. There is no rule that a project can't use both nosql when appropriate and relational when appropriate.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.