Good architecture for 2-tier(client-server) desktop application using linq-to-sql

Question

Hi, Our present architecture - UI,BusinessLayer,DAL(generated linq-to-sql).In the DAL layer, we have added validation logic for entities in partial class. We are directly using entities generated by linq-to-sql in businesslayer(which is bunch of classes - class\form).Also, in these bll classes,we create linq-to-sql queries.

I feel we could layer the application better in terms of MVP pattern, and have service classes which provide data using linq-to-sql.What do you think? Should I consider repository pattern ? Would that be an overkill ?

Answer 1

It is a good idea!

Your choise depends on your application, but these are many problems:

1) The transformation between the object database model and object model application can be much more difficult. In such cases, it is impossible to implement filters on a model for the application so that the resulting query can be trasmited into SQL.

2) Often, as a result of sampling necessary to obtain the result of the connection (JOIN) multiple tables, and not only data from one table

3) Not all SQL-operations and functions have their equivalent in LINQ

What about Entity Framework? Please, don't touch Entity Framework. It is heavy and slow thing! :)

I prefer classical data access via stored proc and Data Access from MS Enterprise Library. I can use the power of SQL and flexibility my own Business Entities. And of course - performance! The reverse of the medal is more work. I used some tools to autogenerate data access objects and then fix them as I need.

Luck!

Answer 2

All good things to be thinking about, but as you start down this path I'm sure you'll have more questions than answers a lot of the time!

I'm going to assume you're using Windows Forms when you mention Desktop and Linq-To-SQL, which will give you a few challenges in implementing something such as an MVP pattern.

While there are pre-tailored MVP frameworks for WinForms (MVC# comes to mind), if you're not developing large-scale apps then you may want to start gently and implement some of the concepts using your own code.

Jeremy Miller's excellent Build Your Own CAB series of articles is a great resource here, as you can take some of the first few ideas out of there and get some separation of concerns between your forms (Presentation) and business logic (Presenters and Service classes).

Jeremy uses mainly a Supervising Controller design in his work (which I love), but its worth looking at other patterns such as Passive View and Model-View-ViewModel (which is baked into the WPF way of working, so worth understanding), to see what you feel most comfortable with.

As for your question on service classes or repositories, I'd think the main two levels of logic you'd want is Presenter or ViewModel entities, and then Service entities below that which can contain things like your Linq-To-SQL queries. So you may already have much of the logic for your Service layer there, but it's more a case of refactoring it into a consistent form.

Answer 3

It sounds like you are on the right track. If you had a WCF service layer your could run it in process or via HTTP which means you could support a client server type application rather than hitting the DB from the front end, but it really depends on your application.

Answer 4

MVP can be hard to understand for developers, but you could give it a go.