Current Best Practices
-
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused. I've broken my questions down into fundamental parts for clarity. 1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice? 2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice? 3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples? I know this is a broad question and answers may be personal choice but any guidance is greatly appreciated.
-
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused. I've broken my questions down into fundamental parts for clarity. 1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice? 2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice? 3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples? I know this is a broad question and answers may be personal choice but any guidance is greatly appreciated.
dhofferber wrote:
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused.
Ditto :)
dhofferber wrote:
1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice?
I dislike any database-application that has more than three tiers, just to be able to say that they have tiers. The DB is already a layer, it's an abstraction I can build on without regard for the logical structure on disc. The UI is a layer in my book, and the two are simply woven together. No fancy ORM unless there's more than 10 tables. No unused layers, no layers that are merely glue and pass the info blindly to their neighbours. KISS, as simple as possible. You do not want to maintain a layer and have to test that extra code if it does not provide an additional benefit.
dhofferber wrote:
2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice?
Sql92, using the IDbInterfaces, on a virtualized datagridview. I do use Linq, but only for manipulating in-memory collections.
dhofferber wrote:
3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples?
What do you define as an "architecture"? I like the architecture of CSLA.NET, but usually stick to something that can be found on MSDN. Architecture is a broad subject, and the basic models are well known; there's enough examples on client/server, three-layered database-apps and webservices. A valuable addition to the architecture of the current applications was the Managed Extensibility Framework[^]. Northwind has a successor, called AdventureWorks.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it
-
dhofferber wrote:
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused.
Ditto :)
dhofferber wrote:
1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice?
I dislike any database-application that has more than three tiers, just to be able to say that they have tiers. The DB is already a layer, it's an abstraction I can build on without regard for the logical structure on disc. The UI is a layer in my book, and the two are simply woven together. No fancy ORM unless there's more than 10 tables. No unused layers, no layers that are merely glue and pass the info blindly to their neighbours. KISS, as simple as possible. You do not want to maintain a layer and have to test that extra code if it does not provide an additional benefit.
dhofferber wrote:
2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice?
Sql92, using the IDbInterfaces, on a virtualized datagridview. I do use Linq, but only for manipulating in-memory collections.
dhofferber wrote:
3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples?
What do you define as an "architecture"? I like the architecture of CSLA.NET, but usually stick to something that can be found on MSDN. Architecture is a broad subject, and the basic models are well known; there's enough examples on client/server, three-layered database-apps and webservices. A valuable addition to the architecture of the current applications was the Managed Extensibility Framework[^]. Northwind has a successor, called AdventureWorks.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it
Thanks for the well thought out response. Microsoft is pushing the Entity Framework with DbContext for all new development. They actually say that datasets have reached an end. Any thoughts? Anyone? P.S. I'm talking about an Entity Framework example called Northwind.Net
-
Thanks for the well thought out response. Microsoft is pushing the Entity Framework with DbContext for all new development. They actually say that datasets have reached an end. Any thoughts? Anyone? P.S. I'm talking about an Entity Framework example called Northwind.Net
-
Thanks for the well thought out response. Microsoft is pushing the Entity Framework with DbContext for all new development. They actually say that datasets have reached an end. Any thoughts? Anyone? P.S. I'm talking about an Entity Framework example called Northwind.Net
Hi Maybe checkout Domain Driven Design (DDD) and some O/RM like Entity framework or NHibernate. There are some more lightweight persistence frameworks if these are too much (Dapper for example). Common to these frameworks is an attempt to consolidate core business logic into a domain model. That way you can concentrate on the interesting code and make it testable. Perhaps some Test Driven Design (TDD)? //Jonathan
-
Hi Maybe checkout Domain Driven Design (DDD) and some O/RM like Entity framework or NHibernate. There are some more lightweight persistence frameworks if these are too much (Dapper for example). Common to these frameworks is an attempt to consolidate core business logic into a domain model. That way you can concentrate on the interesting code and make it testable. Perhaps some Test Driven Design (TDD)? //Jonathan
Thanks Jonathan. My research so far is leading me to Entity Framework - Code First. EF 5 now includes data binding and automatic migrations (db Updates) both of which were needed. Code First seems to be the preferred method and best supported. Linq to Entity or Linq to SQL both look good for the queries. I have been reading about Test Driven Design and like the concept. Writing code to fail and then fixing it seems a bit odd at first but I understand why it could work.
-
I've been a developer for many years. Lately doing a lot of VB6 to VB.Net conversion work. Mostly database driven desktop WinForm apps using SQL. I want to update my design work to current best practices (I'm old school) but there is so much to choose from I'm really confused. I've broken my questions down into fundamental parts for clarity. 1. The use of N-Tier architecture appears best. In my case 3-tier (GUI>DB IF>DB). Do you agree? Other advice? 2. I currently use datasets with filtered databinding. I see Linq, SQL queries and Entity Framework as newer options. Which might be better? Combination? Other advice? 3. Can you point me to good examples of good architecture and coding methods? I'm currently studying Northwind.Net. Other good examples? I know this is a broad question and answers may be personal choice but any guidance is greatly appreciated.
All the questions you have asked are hard to answer without business requirements. My personal opinion is use whatever technology you understand best and is best for the job. The important gotcha with this is you also need to spend time learning new technology all the time (but really? is that not required anyway?). Also, the biggest suggestion of technology and pattern practice I can give anyone is Inversion of Control or Dependency Injection. It is absolutely amazing what you can do with it and it is really simple to implement. It also promotes decoupling and good design/seperation of classes. Makes the lives of Dev and Test a million times easier hands down.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo