CODEWITHSUNDEEP
c#orm
CJ7
CJ7

Reputation: 23275

Would Entity Framework be an overkill for a small-business app?

I am creating a C#/SqlServer app in a small business for specific industry. It is a rewrite of a VB6 app which had almost 100 database tables. It does not sit in a larger enterprise structure of applications and databases like some applications might. It is standalone and will only ever have about a 1-3 developers working on it.

Would Entity Framework be an overkill for such an application? I am looking for at least a micro-ORM to simplify the data-access parts of the app, but is a full blown ORM an overkill?

EDIT: I would have thought ORMs largely suit larger development environments.

Upvotes: 1

Views: 548

Answers (3)

Max Lambertini
Max Lambertini

Reputation: 3719

It is definitely not overkill.

In my workplace we either use EF4.1 or our own ORM. It does speed up development, avoiding you to write glue code to map rows to instances.

We use SQL only when

  • performance trumps code readability/maintanability
  • we have queries that ORM just can't handle

Upvotes: 2

theor
theor

Reputation: 1595

An ORM is overkill only if you feel it this way. With a hundred tables, it looks justified.

You might prefer some micro ORM (like SimpleData or Massive), but it's up to you : a micro-orm might involve a too lose coopling with your DB when EF forces the strong typing.

Upvotes: 0

Marc Gravell
Marc Gravell

Reputation: 1062550

Whether EF is "overkill" depends entirely on the context; indeed, you mention "quite a heavy later", but in many ways that is irrelevant for a "small-business app", since you won't ever be subjecting it to massive load. You could even argue, then, that doing anything but using an ORM is overkill (in that it adds development effort).

You also mention micro-ORMs; indeed they will reduce a lot of raw ADO.NET code (which you single out in the comments). Simple.Data provides a nice layer of abstraction, aboiding the need to write the TSQL too - probably not a bad starting point, but with 100 tables, I can see a lot of attractive aspects of EF/L2S/etc (in particular for stubbing out all your objects). However, EF does itself have plenty of... "features" (meaning: places to stub your toes), which mean you will still have to learn some of how EF wants to work. Invariably, all abstractions do this to some extent - so it a case of weighing up this cost vs the cost of doing more manually.

Upvotes: 3

Related Questions