Developing commercial enterprise level software,; Backend ?

dnme

I was involved in a discussion recently with a company who are about to embark on the developement of an enterprise level ERP type suite of software dedicated to a particular industry which they operate in. The long term plan is to sell the software to to other players in the same industry.

One discussion that seems to be up for grabs is open source versus paid? Some are on the side of using Java with a MySql or Postgre Sql backend while others are comitted to C# / Sql Server.

Their main argument against the later seems to be financial. They argue that the licensing of Sql will impact on costs and competitiveness. i.e. If they sell the prodcut to a customer, that customer will also have to fork our for a Sql Server licence / instance.

My argument is that at this enterprise level, the costs of installing Sql Server are trivial maybe adding a couple of k to the overall price. Also that c# is widely used throughout the software community and very heavily supported in terms of training and sheer saturation. I also argue that SQL Server is likewise, widely used and supported whereas open source versions of the products may not be.

I'm insterested to hear What you think? It must be a question that gets addressed regularly for commercial developers. Am I right? Wrong?

stevenmu

IMHO choosing your DB solution is going to be more critical than choosing your programming language.

I would be inclined to agree that for enterprise level software the costs involved with SQL Server are pretty trivial. And I'd agree that for large segments of industry SQL Server would tend to be more commonly in place and/or supportable. It's (IMHO) more common that SMEs would have people capable of maintaining SQL Server and infrastructure such as backup solutions to support it. This would be critical if your customers would be expected to handle day to day maintenance themselves.

If you have potential customers already lined up, a great idea would be to survey (or even informally chat to) them, explain the pros and cons of each and gauge how they would feel about the different options.

Another option to consider might be make your software DBMS agnostic, enable it to work with all 3, or if you want to focus on one in particular to at least write it in such away that you could easily add support for the others.

Giblet

If you use something like nHibernate, or write an independent layer that can be injected into your implementation you have more options to switch between different backends.

dnme

Giblet wrote: »

If you use something like nHibernate, or write an independent layer that can be injected into your implementation you have more options to switch between different backends.

Is nHibernate an ORM? If so why do I need it? Don't I get many ORM options out of the box with .Net / Visual Studio anyway? and can't I implement backend agnosis with native .Net ?

Giblet

You get one unless you count Linq2Sql which is gone now.
It's just an option that does more of that the hard work than EF does and allows more complex configuration options.

stevenmu

dnme wrote: »

Is nHibernate an ORM? If so why do I need it? Don't I get many ORM options out of the box with .Net / Visual Studio anyway? and can't I implement backend agnosis with native .Net ?

You can "do" ORM out of the box, at it's core ORM is really only having database tables, objects and serialisers/deserialisers to write your objects to the tables, and load your objects from table. You can do all of that by hand very easily, but if you have lots of tables with straightforward relations it can be very tedious too. Tools like nHibernate (and there's plenty of others too such as Microsoft's Entity Framework) do a lot of the legwork for you, so you're not stuck writing lots of repetitive procedures with lots of repetitive SQL statements.

ORM isn't really necessary for back end agnosis either, it's more a case of it coincidentally makes it easier. Generally any type of tiered pattern can be made database agnostic, ASP.Net MVC for example is database agnostic, as long as you don't put anything database specific into it.

You can do it all "out of the box" if you like, but by employing and combining some of the tools out there, like MVC and the Entity Framework you can save huge amounts of effort and time.

dnme

Reading a bit on the topic, I see a lot of issues when it comes to more subtle DB schemas such as stored procs, triggers, etc and the notion of database agnosis. I'm wondering would the Enitiy Framework be a more useful layer than nHibernate? It would certainly fall under the "well supported" argument above but technically what would you think?

Lets say you have a commercial software suite. A BL layer, then a DAL, then a DB logic layer (stored procs, triggers, functions and lots of complex sql and complex joins etc here) and finally the data itself.

Would you recommend Entity Framework over nHibernate? (that's the feeling I'm getting from my research online)