2

Many of my enterprise applications contain an architexture of multiple c# solutions as I describe below.

I have one class library that contains classes and interfaces to represent information. For example, one class represents a user and contains appropriate properties. Similar to structs. Any of my other projects can reference this project for global understanding of the objects transferred between them. There is little or no logic in this project. I call this my "Repository."

I have a seperate solution that handles access to persistence. It is pretty much just wrappers around calls to gather data from persistence sources (Databases, Websites, Files, etc). The sets of information it receives is formatted into the class(es) of my "Repository". There is little or no logic in this project. I call this my "Persistence Access" or "Data Access." This solution also includes mostly integration tests and maybe a couple unit tests.

I have a seperate solution that has organized classes and methods for logic. Whenever a customer application (webservice, wpf, web, android) needs a logical output determined by the business requirements of my company, a method is logically organized into one or more of these classes. This project makes calls to my "Persistence Access" and can receive and output either in the form of generic types/collections, or in the form of one of my "Repository" types. This project contains multiple classes and almost all of the enterprise application's logic according to business requirements. I call this my "Business Logic." This solution also includes mostly unit tests, and maybe a couple integration tests.

I have an asp.net web application project. My web application has javascript, css, aspx, codebehind files, and some other basics that naturally come along with these things (some ashx). If a page requires logic or data in order to determine what is displayed on the page, the Code Behind file calls the "Business Logic" to make those determinations. The only thing the asp.net aspx objects do are format that information. I call each of these pages "views" or "ViewModels." This application contains very few tests as it's mostly just aspx, xhtml, css, and a couple protected event handlers in codebehind. (Maybe some tests on ashx file(s).)

My Confusion is This: In ASP.Net Web Development Terms, I like to say I'm using a Model-View-Controller architecture. But I am NOT using the Microsoft MVC Web Application because I want to seperate my business logic completely out of the website.

So is it correct to say I use MVC? I HAVE Created MS MVC Web Apps before, but for complex projects that may have more than one use for the business logic (which is most of them), I use this architecture I have described. Or, am I using some other pre-named architecture? I want to know the architectural pattern name as it pertains to Web Development. So MVVM doesn't immediately sound pertinent to me per se.

tereško
  • 56,151
  • 24
  • 92
  • 147
Suamere
  • 4,460
  • 1
  • 37
  • 47
  • ViewModels are usually POCO objects containing data that is passed to your view from your application, so something doesn't sound right when you call aspx pages ViewModels. Views - yes, ViewModels- not sure. – m0s May 12 '14 at 00:26
  • 5
    This question appears to be off-topic because it does not describe a particular problem that can be solved. It is better suited for [programmers.stackexchange.com](http://programmers.stackexchange.com/) – Matt Johnson-Pint May 12 '14 at 00:27
  • @MattJohnson, you're right. If this had to be moved I'd understand. – Suamere May 12 '14 at 00:42

2 Answers2

7

You have an MVC front end.

Your architecture is N-Layer (clear separation.. but separated by responsibility, not by physical location. That would be N-Tier).

Your domain is commonly referred to as an Anaemic Domain Model - it has no actual business logic in the domain. All logic resides in services.

Yes it is correct to say you "use MVC".. since that generally refers to the front-end setup when talking web applications. MVC isn't normally a term that is used solution-wide.. although it technically can be applied in that way, it generally isn't (in the ASP.NET world anyway).

If you were to be explaining your setup to someone, I would say: "I have an N-Layer solution, where layers are separated into assemblies with an ASP.NET MVC front end.".

Simon Whitehead
  • 57,414
  • 7
  • 93
  • 127
  • Thanks, Simon. Even knowing these practices, I hadn't put them together in a short description so eloquently. – Suamere May 12 '14 at 00:44
0

From your description it is hard to tell whether you are using MVC architecture or no. Your architecture may not be any of those architectures that have a common name.

If you are using ASP.NET web forms then your application is probably not MVC, because your controller - which is most likely your code behind file is tightly coupled with your View- your aspx file.

m0s
  • 3,952
  • 8
  • 36
  • 60
  • 1
    Right, but my controller is not in the codebehind. The codebehind calls what would be the controller layer as an external logic layer and there is no coupling. – Suamere May 12 '14 at 00:48
  • @Suamere In that case, given you can distinguish your M, V & C and they are not tightly couple then it is MVC. There is a very good discussion on MVC & MVP here worth reading http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference – m0s May 12 '14 at 01:36