Архитектура программы Asp.Net

Question

Я только что взял новое приложение Asp.Net MVC, и после его открытия я нахожу следующее:

1. [Проект] .Web
2. [Проект] .Models
3. [Проект] .BLL
4. [Проект] .DAL

Теперь, кое-что, что становится ясным, это то, что есть данные, которые должны сделать очень много, прежде чем они попадут в View (База данных> DAL> Repo> BLL> ConvertToModel> Controller> View). DAL - это Subsonic, репозитории в DAL возвращают дозвуковые объекты в BLL, которые обрабатывают их, делают сумасшедшие вещи и преобразуют их в модель (из .Models), иногда с классами, которые выглядят следующим образом

public DataModel GetDataModel(EntityObject Src)
{
    var ReturnData = new DataModel():
    ReturnData.ID = Src.ID;
    ReturnDate.Name = Src.Name;

    //etc etc
}

Теперь возникает вопрос: "Это полное перебор"? Хорошо, проект имеет приличный размер и может только стать больше, но стоит ли продолжать все это? Я не хочу использовать AutoMapper, так как кажется, что это усложняет ситуацию. Кто-нибудь может пролить свет на это?

Answer 1

Теперь возникает вопрос: "Это полное излишество"?

Да, это излишне. Кто-то пытается создать приложение 3-Tier / n-Tier и MVC, не понимая, что в зависимости от вашей точки зрения MVC сам по себе является одним из способов, с помощью которого можно создать приложение n-Tier, с каждым основным / традиционным уровнем уже одна часть аббревиатуры MVC, или альтернативная архитектура, которую вы используете вместо n-уровня. В любом случае, видеть классы DAL / BLL вместе с MVC немного странно.

Также следует помнить, что у вас может не быть просто веб-приложения. Иногда существует «умный клиент» winforms или другое приложение, которое обращается к той же базе данных и действительно является частью той же системы & mdash; например, потребитель сталкивается с представлением сайта электронной коммерции и представителем отдела продаж одной и той же базы данных инвентаризации. В этом случае традиционные DAL и BLL могут быть хорошей идеей, потому что они могут быть разделены между различными приложениями в системе. Но если вы делаете это, вы, вероятно, должны вместо этого взглянуть на сервисный уровень.

Answer 2

Сначала , я думаю, что ваше нежелание использовать AutoMapper удивительно нелогично. Я вижу причины не использовать другую стороннюю библиотеку, но в этом случае AutoMapper действительно не усложняет ситуацию, если вы подключите ее правильно и в нужных местах (т.е. только в одном месте ...).

Во-вторых, , вся ASP.NET MVC Framework возникла из желания дать разработчикам возможность создавать слабосвязанные, масштабируемые и «подключаемые» приложения. Это означает больше работы, чтобы сделать то же самое, если вы собираетесь выбрать один путь, а затем идти по этому пути, это правильно. Но как только вы примете решение что-то изменить - возможно, вы решите перейти от Subsonic к другому провайдеру или, в конце концов, использовать AutoMapper - вы заметите, что вам нужно только переписать соответствующие части вашего приложения, вместо этого всего этого.
(Я не говорю, что вам придется переписывать приложение WebForms с нуля, если вы, например, переключаете ядро ​​базы данных, но вам придется просматривать почти весь код приложения, чтобы обновить соответствующие части кода, если вы не усердно работали достаточно развязки. В этом случае вы не сохраняете работу, выбирая WebForms вместо MVC ...)

Короче говоря: Да, это означает, что для вас больше работы, чем просто "взломать что-то вместе". И это выглядит сложнее, чем может показаться необходимым. Но как только вы начнете передумывать о чем-то (и вы это сделаете), вы похвалите свою счастливую звезду за то, что вы сделали это «правильным образом» * с самого начала.

*) Нет такой вещи. Я знаю.