recommendation on design/architecture for centralized DB application in .net

Question

I am a junior .NET programmer. I have to develop an applicaion that handles sales, customers and providers (among another very large number of things) on a local environment for a small number of users (around 8). The whole thing should be created for local use with a centralized database. My architecture would be something like this from top to bottom:

1.UI on windows forms.

2.Controller for handling user requests

3.Bussines objects that are Entity Framework generated objects

4.SQL Database.

Obviously I already know that is not the best approach for architecture, yet I want to keep it as simple as possible. I've done a lot of research but the number of questions seems to widen so I was looking for some guidance for this particular problem so I can focus in researching after having a recommended architecture I feel comfortable with. Sorry about uberasking this question I'm just overwhelmed with the options.

Tnx for helping a newb.

Answer 1

What you've described seems like a good approach coming form a junior developer level.

There are many factors that affect what architecture is appropriate for a project. Time, schedule, money, simplicity or complexity, maintainability and future development expansion versus a one-and-done application. Will likely future versions require a massive rewrite anyway due to the data model or integration with some unknown system?

No application is ever perfect after the first iteration. Any good developer will find a myriad of ways to improve a project after it is finished as their technical skills and knowledge grow.

That being said, the Database and Entity Framework side of things is perfectly fine. EF will get you focusing on features quickly instead of infrastructure. You may have already weighed EF against other object model suites, or a traditional stored procedure based approach.

The UI is probably dictated by the client or a business need. The only other big decision here would maybe be an intranet web application so you don't have to worry about installing software on users' machines.

The controller / class library / business layer makes sense so you don't have to be writing queries against EF directly in your winforms code. This allows you to more easily rip out the UI and replace it with something else down the line.

Nothing you've outlined throws up any red flags without knowing the exact situation. Move forward with that approach, and see how it goes. When you're done, think about what aspects of the architecture were challenging to deal with, were redundant, or otherwise troublesome.

Answer 2

Since as you said the Entity Framework objects are generated, you may want to have one or more Model levels between the Controller and the Entity objects. It is quite often that a specific View has data coming from more than one Entity. If you do not have another level of Models that the Controllers can access, what generally happens is that the Business Logic migrates to the Controllers.

In other words, the Controller would create the Model, and the Model would know how to interact with the Entities.

Note that I am assuming you are using an MVC pattern since your reference of Controllers in #2.