CODEWITHSUNDEEP
c#asp.net-mvcentity-framework
ditoslav
ditoslav

Reputation: 4872

How to hide business logic data from web project in enterprise level application

I'm making a website using mvc.net 4 which will connect to a database via entity framework 6.

I've been following

http://www.codeproject.com/Articles/990492/RESTful-Day-sharp-Enterprise-Level-Application#_Toc418969124

and they suggest splitting up an application into data layer, business entities, business logic and web app.

Now, since I'm making a simpler application I was hoping to simplify from making 4 projects and instead make a data and business logic layer called "Business" which connects to a database in this case and expose the data via API which will be in the "Business" layer which will incorporate the other 3 (Business logic, business entities and data layer).

What bothers me is that entity framework generates entities as public so it's an obvious problem since I want it to stay hidden from the web app.

Should I make all the entities private or make a project between the EF6 generated entities and the "Business" layer?

Upvotes: 0

Views: 877

Answers (1)

JasCav
JasCav

Reputation: 34642

I believe you're getting a bit confused about the design and separation of concerns versus the access modifiers on the classes.

To take a step back and get a high-level overview, first look at your typical application structure.

  • Data Layer - At the lowest level, this is a 1:1 representation with the database. This is where your data is mapped out and is normalized properly, etc.
  • Business Data Layer - A step up from the data layer is the business layer (and specifically the data components). These data components better represent how things work in the "real world" in the sense that they better model what actually happens.
  • Business Logic Layer - Oftentimes paired with the above layer, this layer encapsulates the logic for how the business data works together.
  • Presentation Layer - Display all the above "stuff." Note that this layer may also have its own set of data because the way you display business objects may not map 1:1, so there might have to be some translation from the business data to actually how your users are going to view that data.

With that in mind, you mention that you are using Entity Framework. Entity Framework is an ORM which maps your objects to incompatible relational types creating sort of a "database in objects" (or a "virtual object database" as Wikipedia puts it). One thing to keep in mind here is that EF is just how you are managing your data objects within your system. It makes life easier in many ways, but it is not the actual data. The fact that the classes are "public" is a requirement of EntityFramework, yes, but it does not mean that you need to allow access to or use those data objects in other parts of your project (although, there is a caveat to that which I will get to in a moment).

So, at this point, you could create an application that might look like this:

  • Data Objects (using EF to help manage/use them)
  • Business Layer (converts the data layer into business objects, provides business logic)
  • View Layer (AKA maybe a website) - Leverages the business layer to display information in a consistent and cohesive way to the user.

My caveat from before - please note that the next layer up does need to know about the layer below it. If you think about that logically, how are you going to create a business layer if you have no data to build off of? But, the view layer should not be directly touching your data objects directly and your business logic should (generally) not be using the data objects to make business decisions. There is a sort of conversion step in moving between the layers.

If that is all clear, then, back to what you are asking. How much you split out or don't split out the layers is really up to you as the designer. I have seen the data layer sit directly in the same project as the business logic - particularly if there is no real business logic. Heck, I have seen a very simple application put everything in a single WebApp project. You have to think through what your project currently needs and what the benefits and negatives are if you design things a certain way.

Some things to think about:

  • If you separate layers, it becomes easier to change the system. (e.g. if some new business logic is added, you don't need to change your data layer to support it - you can change it in one place)
  • The more layers you have, the more there is to "juggle." Oftentimes, people new to this see themselves doing a lot of conversions and manual code back and forth between objects. Look at tools like AutoMapper to help automate this quite a bit.
  • If you're just learning the technology, don't spend a ton of time overdesigning this. You're progress will be slower and you may end up getting frustrated.
  • If you're working on a big enterprise application (where one team is working on each layer, for example) or where it can change a lot, splitting this out can really help keep code modular and allow each team to work while only needing to know the interfaces that the other team is providing. Makes life much nicer as it reduces coordination.

There are lots of other articles out there on this type of design. I would recommend hitting up Google to read more. Hopefully this clarifies things a bit!

Upvotes: 3

Related Questions