4

I'm hosting a solution that serves as a web tier on a Ubuntu machine running Apache and Mono. I'm currently developing the project on OSX, using Mono. I understand there is no native support for Linq to SQL in Mono, so I've been going old school and developing stored procedures for my database interaction. I use ADO.NET for connectivity.

Development is painstakingly slow. Whenever I make a change to a stored procedure, I must update fields all across my architecture. I've gotten very lazy in terms of being able to easily delete an entity in Linq to SQL and have my objects updated with new fields.

It feels like development is taking 10x as long as it would natively in .NET in Windows.

Is there a better architecture I could be using for my database connectivity?

While the methodology I'm adhering to is straightforward and works fine, it's simply a slow approach.

George
  • 361
  • 2
  • 8

1 Answers1

3

Well, you could use a DataMapper (often called "object relational mappers") to provide persistence services to your application. LinQ-To-SQL basically is a DataMapper, too.

Good DataMappers are for example NHibernate and Subsonic, which can be used with a variety of databases. Microsoft also introduced the ADO.NET Entity Framework a few years ago, which has probably got better design time support in Visual Studio than both the others.

Here's also a comparison of ORMs.

Personally, I use (N)Hibernate quite often. It does a great job when you really want a persistence-ignorant model and it is very mature.

However, I don't really know if it'll speed up your development that much. Often times fields have to be dragged through the whole application. It's just a matter of fact. With an ORM, you mostly have to add the field to the entity, the database and the mapping. I doubt that's much better than your current scenario.

In classical ADO.NET with typed datasets you just need to alter the DataAdapter's queries and the dataset's schema, which isn't much worse to the ORM solution. Your problem is probably the tedious procedure layer. A procedure layer is only a good idea when you want to restrict data access for your (database-)users.

I think your real problem is the lack of design time support for your current architecture.

Community
  • 1
Falcon
  • 19,248
  • 4
  • 78
  • 93
  • 1
    +1 for nhibernate; probably the only way to fly here. – Wyatt Barnett Aug 09 '11 at 17:06
  • I researched nHiberate before posting this question and it didn't look like it supported OSX. The only downloads I was able to find were for windows. – George Aug 09 '11 at 18:08
  • @George: You're using Mono. All you need are the binaries. You won't find an OSX. Just use the provided DLLs. It works with Mono according to the Mono website: http://www.mono-project.com/Database_Access – Falcon Aug 09 '11 at 18:16
  • @George: Also, please dive a little deeper into the .NET Framework / Mono. This is a managed platform, the binary code is independent of your OS/system architecture. – Falcon Aug 09 '11 at 18:18